Version Control for Definition

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

  • Check ComponentDefinition Revision

Note: there are only one revision of definition if you never update it.

  1. $ vela def get webservice --revisions
  2. NAME        REVISION    TYPE        HASH            
  3. webservice  1           Component   dfa072dac5088ed8
  4. webservice  2           Component   519e11eb7cbe9cdd
  • Check TraitDefinition Revision
  1. $ vela def get affinity --revisions  
  2. NAME            REVISION        TYPE    HASH            
  3. affinity        1               Trait   9db54dd8d5314bd5
  4. affinity        2               Trait   8bf3e82a6884db2c
  • Check PolicyDefinition Revision
  1. $ vela def get override --revisions
  2. NAME            REVISION        TYPE    HASH
  3. override        1               Policy  f6f87a5eb2271b8a
  • Check WorkflowStepDefinition Revision
  1. $ vela def get deploy --revisions
  2. NAME    REVISION        TYPE            HASH
  3. deploy  1               WorkflowStep    2ea741dae457850b

The best way to control version is using a new name for every definition version.

Specify Component/Trait Capability Revision in Application

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

System admin can also write a webhook to inject the version automatically.

  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 always use the latest revision when you upgrade your application.