Version: v1.1

Revisioning

Component Revision

You can specify a generated component instance revision with field spec.components[*].externalRevision in Application like below:

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4. name: myapp
  5. spec:
  6. components:
  7. - name: express-server
  8. type: webservice
  9. externalRevision: express-server-v1
  10. properties:
  11. image: stefanprodan/podinfo:4.0.3

If the field is not specified, it will generated by the name rule <component-name>-<revision-number>.

After the Application created, it will generate a ControllerRevision object for each component.

  • Get the revision for component instance
  1. $ kubectl get controllerrevision -l controller.oam.dev/component=express-server
  2. NAME CONTROLLER REVISION AGE
  3. express-server-v1 application.core.oam.dev/myapp 1 2m40s
  4. express-server-v2 application.core.oam.dev/myapp 2 2m12s

You can specify the component revision for component rolling update.

Specify Component/Trait Capability Revision in Application

When the capabilities(Component or Trait) changes, KubeVela will generate a definition revision automatically.

  • Check ComponentDefinition Revision
  1. $ kubectl get definitionrevision -l="componentdefinition.oam.dev/name=webservice" -n vela-system
  2. NAME REVISION HASH TYPE
  3. webservice-v1 1 3f6886d9832021ba Component
  4. webservice-v2 2 b3b9978e7164d973 Component
  • Check TraitDefinition Revision
  1. $ kubectl get definitionrevision -l="trait.oam.dev/name=rollout" -n vela-system
  2. NAME REVISION HASH TYPE
  3. rollout-v1 1 e441f026c1884b14 Trait

You can specify the revision with @version approach, for example, if a user want to stick to using the v1 revision of webservice component:

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4. name: myapp
  5. spec:
  6. components:
  7. - name: express-server
  8. type: webservice@v1
  9. properties:
  10. image: stefanprodan/podinfo:4.0.3

In this way, if system admin changes the ComponentDefinition, it won’t affect your application. If no revision specified, KubeVela will use the latest revision when you upgrade your application.

Application Revision

When updating an application entity except workflow, KubeVela will create a new revision as a snapshot for this change.

  1. $ kubectl get apprev -l app.oam.dev/name=myapp
  2. NAME AGE
  3. myapp-v1 54m
  4. myapp-v2 53m
  5. myapp-v3 18s

You can get all the information related with the application in the application revision, including the application spec, and all related definitions.

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: ApplicationRevision
  3. metadata:
  4. labels:
  5. app.oam.dev/app-revision-hash: a74b4a514ba2fc08
  6. app.oam.dev/name: myapp
  7. name: myapp-v3
  8. namespace: default
  9. ...
  10. spec:
  11. application:
  12. apiVersion: core.oam.dev/v1beta1
  13. kind: Application
  14. metadata:
  15. name: myapp
  16. namespace: default
  17. ...
  18. spec:
  19. components:
  20. - name: express-server
  21. properties:
  22. image: stefanprodan/podinfo:5.0.3
  23. type: webservice@v1
  24. ...
  25. componentDefinitions:
  26. webservice:
  27. apiVersion: core.oam.dev/v1beta1
  28. kind: ComponentDefinition
  29. metadata:
  30. name: webservice
  31. namespace: vela-system
  32. ...
  33. spec:
  34. schematic:
  35. cue:
  36. ...
  37. traitDefinitions:
  38. ...

Live-Diff the Application

Live-diff helps you to have a preview of what would change if you’re going to upgrade an application without making any changes to the living cluster. This feature is extremely useful for serious production deployment, and make the upgrade under control

It basically generates a diff between the specific revision of running instance and the local candidate application. The result shows the changes (added/modified/removed/no_change) of the application as well as its sub-resources, such as components and traits.

Assume we’re going to upgrade the application like below.

  1. # new-app.yaml
  2. apiVersion: core.oam.dev/v1beta1
  3. kind: Application
  4. metadata:
  5. name: myapp
  6. spec:
  7. components:
  8. - name: express-server
  9. type: webservice@v1
  10. properties:
  11. image: crccheck/hello-world # change the image

Run live-diff like this:

  1. vela live-diff -f new-app.yaml -r myapp-v1

-r or --revision is a flag that specifies the name of a living ApplicationRevision with which you want to compare the updated application.

-c or --context is a flag that specifies the number of lines shown around a change. The unchanged lines which are out of the context of a change will be omitted. It’s useful if the diff result contains a lot of unchanged content while you just want to focus on the changed ones.

Click to view the details of diff result

  1. ---
  2. # Application (myapp) has been modified(*)
  3. ---
  4. apiVersion: core.oam.dev/v1beta1
  5. kind: Application
  6. metadata:
  7. - annotations:
  8. - kubectl.kubernetes.io/last-applied-configuration: |
  9. - {"apiVersion":"core.oam.dev/v1beta1","kind":"Application","metadata":{"annotations":{},"name":"myapp","namespace":"default"},"spec":{"components":[{"externalRevision":"express-server-v1","name":"express-server","properties":{"image":"stefanprodan/podinfo:4.0.3"},"type":"webservice"}]}}
  10. creationTimestamp: null
  11. - finalizers:
  12. - - app.oam.dev/resource-tracker-finalizer
  13. name: myapp
  14. namespace: default
  15. spec:
  16. components:
  17. - - externalRevision: express-server-v1
  18. - name: express-server
  19. + - name: express-server
  20. properties:
  21. - image: stefanprodan/podinfo:4.0.3
  22. - type: webservice
  23. + image: crccheck/hello-world
  24. + type: webservice@v1
  25. status:
  26. rollout:
  27. batchRollingState: ""
  28. currentBatch: 0
  29. lastTargetAppRevision: ""
  30. rollingState: ""
  31. upgradedReadyReplicas: 0
  32. upgradedReplicas: 0
  33. ---
  34. ## Component (express-server) has been modified(*)
  35. ---
  36. apiVersion: apps/v1
  37. kind: Deployment
  38. metadata:
  39. - annotations:
  40. - kubectl.kubernetes.io/last-applied-configuration: |
  41. - {"apiVersion":"core.oam.dev/v1beta1","kind":"Application","metadata":{"annotations":{},"name":"myapp","namespace":"default"},"spec":{"components":[{"externalRevision":"express-server-v1","name":"express-server","properties":{"image":"stefanprodan/podinfo:4.0.3"},"type":"webservice"}]}}
  42. + annotations: {}
  43. labels:
  44. app.oam.dev/appRevision: ""
  45. app.oam.dev/component: express-server
  46. app.oam.dev/name: myapp
  47. app.oam.dev/resourceType: WORKLOAD
  48. - workload.oam.dev/type: webservice
  49. + workload.oam.dev/type: webservice-v1
  50. name: express-server
  51. namespace: default
  52. spec:
  53. selector:
  54. matchLabels:
  55. app.oam.dev/component: express-server
  56. template:
  57. metadata:
  58. labels:
  59. app.oam.dev/component: express-server
  60. app.oam.dev/revision: KUBEVELA_COMPONENT_REVISION_PLACEHOLDER
  61. spec:
  62. containers:
  63. - - image: stefanprodan/podinfo:4.0.3
  64. + - image: crccheck/hello-world
  65. name: express-server
  66. ports:
  67. - containerPort: 80

Furthermore, you can integrate the revision for application snapshot and recovery with your own system.