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
Is your feature request related to a problem? Please describe.
So far we designed auto-updated packages to simply have no Spec.Version set. However, this leads to a lot of added complexity and coupling everywhere in the codebase.
Describe the solution you'd like
We still want to support auto-updates, but we want to have the logic of checking for updates in a separate operator. This decouples the package reconciliation from the auto update aspect, and also it's easier to turn off this feature globally by shutting down this operator/deployment.
At the bootstrapping process, the user should be asked whether the auto-update-operator should be installed (default yes).
As a consequence, this means that all packages must have Spec.Version set at all times (see #341). The new controller will only check if an update is available, and then patch the version field, such that the update is also more transparent to the user.
As always, documentation should be updated.
Additional context
This idea originated when implementing Support versions for dependent packages #311, where we decided to do auto-updates in a different way (i.e. Packages always need to have Spec.Version set.)
In GitOps installations this controller would not be used, as instead the package versions will be set in a git repository. For this we created Package Updates in GitOps installation #339 for a later milestone.
The text was updated successfully, but these errors were encountered:
I don't know if patching the Spec.Version field wouldn't cause problems with GitOps controllers. If you want to pin to a specific version, I think it would make sense to set the Version field and add the current Version to the Status (I'm not sure if this field already exists, but it would definitely make sense).
I don't know if patching the Spec.Version field wouldn't cause problems with GitOps controllers. If you want to pin to a specific version, I think it would make sense to set the Version field and add the current Version to the Status (I'm not sure if this field already exists, but it would definitely make sense).
The idea is to not install this controller in a GitOps environment. I didn't spec it correctly, but I updated the description now.
Is your feature request related to a problem? Please describe.
So far we designed auto-updated packages to simply have no
Spec.Version
set. However, this leads to a lot of added complexity and coupling everywhere in the codebase.Describe the solution you'd like
We still want to support auto-updates, but we want to have the logic of checking for updates in a separate operator. This decouples the package reconciliation from the auto update aspect, and also it's easier to turn off this feature globally by shutting down this operator/deployment.
At the bootstrapping process, the user should be asked whether the auto-update-operator should be installed (default yes).
As a consequence, this means that all packages must have
Spec.Version
set at all times (see #341). The new controller will only check if an update is available, and then patch the version field, such that the update is also more transparent to the user.As always, documentation should be updated.
Additional context
The text was updated successfully, but these errors were encountered: