You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have some setups where we run multiple instances of the same component on a single cluster where it would be desirable to be able to update the component version for each instance separately. Currently, Commodore will use the same version for each component instance, but with the new dependency checkout structure based on worktrees we're able to checkout different versions of a component for different component instances.
Current state
In #559, we provide an implementation which allows suitably written components to be rendered with different versions for different instances. However, there's no logic yet which verifies whether a component will work correctly when checked out in different versions for different instances. See the PR description for a brief overview over the current state of the implementation.
Missing features
We can't support different versions of Jsonnet dependencies for different instances of the same component with the current Jsonnet dependency management architecture. In the draft PR, Commodore makes the Jsonnet dependencies of the "main" non-instantiated component checkout available for all instances. We could possibly achieve support for separate Jsonnet dependency versions per instance, but it would require reworking how we interface with Kapitan's compile() function.
Components must use ${_base_directory} in their compile configuration (parameters.kapitan.dependencies and parameters.kapitan.compile) in order to ensure Helm & HTTPS dependencies are fetched individually for each instance and that the instance's Jsonnet files are picked up by kapitan compile. The draft PR doesn't perform any validation when rendering component instances of the same component with different versions. There's multiple options to handle this: 1) we simply require that compnents advertise instance-versioning support 2) we lint the component classes to check that there's no entries which don't use ${_base_directory} (TBD whether that's feasible for all cases).
The architecture of specifying versions for instances theoretically allows changing the repository URL and sub-path in the repository per instance. However, the implementation in the draft PR doesn't support this yet, as it's unclear how this needs to be modelled in the internal component/alias architecture in Commodore.
Context
We have some setups where we run multiple instances of the same component on a single cluster where it would be desirable to be able to update the component version for each instance separately. Currently, Commodore will use the same version for each component instance, but with the new dependency checkout structure based on worktrees we're able to checkout different versions of a component for different component instances.
Current state
In #559, we provide an implementation which allows suitably written components to be rendered with different versions for different instances. However, there's no logic yet which verifies whether a component will work correctly when checked out in different versions for different instances. See the PR description for a brief overview over the current state of the implementation.
Missing features
compile()
function.${_base_directory}
in their compile configuration (parameters.kapitan.dependencies
andparameters.kapitan.compile
) in order to ensure Helm & HTTPS dependencies are fetched individually for each instance and that the instance's Jsonnet files are picked up bykapitan compile
. The draft PR doesn't perform any validation when rendering component instances of the same component with different versions. There's multiple options to handle this: 1) we simply require that compnents advertise instance-versioning support 2) we lint the component classes to check that there's no entries which don't use${_base_directory}
(TBD whether that's feasible for all cases).Links
The text was updated successfully, but these errors were encountered: