Application versioning

The purpose of this instruction is to give guidance on how to use versioning of application specifications and referencing versions from deployments.

First, a bit of explanation on the versioning mechanisms.

Application versions

An application specification has an optional version field. If you choose to have a version field for your application, the application version is immutable, and you need to modify the version field if you change any part of the application specification. The version field is a string, and the Avassa system does not enforce any syntax or semantics in the string.

You can view the versions of the application specification:

Or using supctl:

supctl --query-params revision-list show --config applications popcorn

- "1.2"
- "1.1"
- "1.0"

supctl --query-params revision="1.0" show --config applications popcorn 

name: popcorn
version: "1.0"
services:
  - name: pop-service
...

Deployments and application versions

A deployment references an application and version.

You can either use “*” as version or a specific version.

• If you use “*”, the latest version as defined above will be deployed.

• And, obviously, if you specify an explicit version, that version will be deployed.

A general behavior of the deployment is that any modifications will take immediate effect when you save it. (The redeploy action is only for re-evaluating labels).

This results in the following possible combinations

Application version	Deployment application version	Result
None	*	The non-versioned application will be deployed. Any modifications on the application specification will be immediately deployed without any needed actions on the deployment.
None	Value	Nothing will be deployed since the explicit version does not exist. Note however that if you edited the version field from “*” to a version value, the application will still be deployed, it is not removed from the sites.
Value	*	Latest application will be deployed. Whenever you modify your application (which also requires changing the version field), the new application will be automatically deployed.
Value	Value	If the given version value in the deployment matches an existing application version that version will be deployed. If the version in the deployment does not match any application version nothing will be deployed. Note also that if you modify the version value in the deployment from an existing application version to a non-existing, nothing will happen, the existing version will stay at the sites.

The last row in the table sometimes lead to “unexpected” behavior. Imagine you have

name: popcorn-deployment
application: popcorn
application-version: "2.0"
placement:
  match-site-labels: ...

And a version 2.0 of the popcorn application that is then already deployed. If you now modify your application to version 2.1 and save it (and leave the deployment above unchanged with version 2.1). Nothing will happen since you have an explicit version reference.

💡 Note: since Avassa does interpret the version string, the notion of “latest” refers to the last edited version. Assume you did (for some reason) the following sequence of versions

• none
• 1.0
• 1.1
• 1.2
• 0.9

The latest version is 0.9 and not 1.2, and if you use * in the deployment, version 0.9 will be deployed.

Image versions

A related question is regarding to how you want to manage your container versions. In the application specification you define the path to the image:

name: popcorn
version: "2.0"
services:
  - name: pop-service
		...
    containers:
      - name: pop-container
        image: registry.gitlab.com/avassa-public/movie-theaters-demo/kettle-popper-manager

or with a tag:

name: popcorn-controller
version: "1.0"
services:
  - name: popcorn-controller-service
    containers:
      - name: kettle-popper-manager
        image: registry.gitlab.com/avassa-public/movie-theaters-demo/kettle-popper-manager:v1.0

So with explicit tags, if you modify the tag in the application specification, the Avassa system will automatically pull the new image version from the repository. But if you modify your container in the registry and want that to be deployed? (This is a scenario which is not recommended in operational phases, should only be used for early developing and experimenting).

The Control Tower provides an action to pull the container: