Clearing the Confusion: A Simplified Guide to Artifact, Component, and Service Versions
Taking a look at a typical service definition in Odin containing a datastore and an application component.
There are three major types of versions involved:
Service version
Component version
Artifact version
Service Version
A service version is a version of the service. Service is a set of components along with their configuration. This version needs to be upgraded whenever there is a change in any of the components in the service definition.
This version is defined at the scope of the service definition. (line 3 in the above example)
This version can be a SNAPSHOT
version or a concrete version. The SNAPSHOT
version of a service can consist of artifacts with SNAPSHOT
versions but the other way around is not true. It is mandatory for a service with a concrete version to have all artifacts with a concrete version.
Component Version
A component version is a version of the component offered by odin. This version has two parts separated by a hyphen. The first part (only available in datastores) indicates the true version of the datastore whereas the second part of the version denotes the version of the default set configuration used by that component.
To help understand better, consider the component version at line 19 in the above example. The first part of the version implies that the MySQL version is 5.7
and there is a default set of configurations involved (say the engine version is 5.7.mysql_aurora.2.09.1
), the combination of both will make the version 5.7-1.0.0
In the case of the application component, there is just a default set of configurations offered by odin. So the version number is just 1.0.0
(without two parts). The list of available application component versions can be viewed by the command
Artifact Version
The artifact version is the version of the code artifact used to deploy the application component. This version can also be concrete as well as SNAPSHOT
. The SNAPSHOT
version of an artifact is allowed to be used in a service with SNAPSHOT
version only.
The SNAPSHOT
versions are overridable. That means you can create multiple artifacts with the same SNAPSHOT
version and the latest will be used for deployment. Whereas a concrete version of an artifact is not allowed to override.
Relationship between the Versions
Consider the above example.
The service version
2.0.0
consists of two components.One is MySQL with a component version
5.7-1.0.0
where MySQL version5.7
will be provisioned.The other is an application component with a component version
1.0.0
and artifact version3.0.0
We can say that the artifact version of the application component will use the default configuration of component version
1.0.0
used in the service definition version2.0.0
Last updated