bump provider-runtime to v0.9.0 and helm to 0.15.4 to fix dependabot vulnerability (docker)
project refactoring
Adds mutating webhook and conversion webhook to support multiple composition versions
Maintaining multiple versions of the same chart is requested - where values can also be different.
With the latest release of core-provider (https://github.com/krateoplatformops/core-provider/tree/0.18.1) is it possible to change the version of the helm chart with the current limit to have a single version served and values that cannot change.
A possible evolution is to let compositionDefinition specify if a version is served or not, deploy a CDC per served version and "force" the CR to be watched from a single specific controller (which could be adding an annotation that specifies the controller that manages it).
So, in order to implement the upgrade of a composition from v1 to v2, these are the steps to be implemented:
pause the composition v1 (with krateo.io/paused: true)
install the composition v2 (without krateo.io/paused annotation or with krateo.io/paused: false)
In case of rollback:
pause the composition v2 (with krateo.io/paused: true)
resume the composition v1 (with krateo.io/paused: false)
CDC is actually using using composition metadata.name as a release name. In order to let composition v2 be an helm upgrade of composition v1, we need to instruct the CDC to take, as a release name, the metadata.name of composition v1. This can be done with a new annotation krateo.io/release-name.
If there's no krateo.io/release-name annotation, the CDC will add it, using composition metadata.name as a value. If the annotation is present, the CDC will use that values as release name.
Adds mutating webhook and conversion webhook to support multiple composition versions
Maintaining multiple versions of the same chart is requested - where values can also be different. With the latest release of core-provider (https://github.com/krateoplatformops/core-provider/tree/0.18.1) is it possible to change the version of the helm chart with the current limit to have a single version served and values that cannot change.
A possible evolution is to let compositionDefinition specify if a version is served or not, deploy a CDC per served version and "force" the CR to be watched from a single specific controller (which could be adding an annotation that specifies the controller that manages it).
So, in order to implement the upgrade of a composition from v1 to v2, these are the steps to be implemented:
In case of rollback:
CDC is actually using using composition metadata.name as a release name. In order to let composition v2 be an helm upgrade of composition v1, we need to instruct the CDC to take, as a release name, the metadata.name of composition v1. This can be done with a new annotation krateo.io/release-name.
If there's no krateo.io/release-name annotation, the CDC will add it, using composition metadata.name as a value. If the annotation is present, the CDC will use that values as release name.