Revisioning

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

    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.

    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
    • Check TraitDefinition Revision
    1. apiVersion: core.oam.dev/v1beta1
    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.

    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-v2   53m
    4. 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.

    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.

    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:

      -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 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

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