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
If possible, lets see if we can deploy all operators to their own namespaces.
That way, if a breaking change happens in an operator (as it did with gitops operator 1.7.0) we could pin it to a Manual installed version very easily.
With many operators sharing the openshift-operator namespace, becomes a lot harder to do this as every operator in the namespace would need to be Manual if one is (linked to the OG/OLM)
The dependency here will be if individual operators support this capability (many do).
The text was updated successfully, but these errors were encountered:
One operator from the set currently used does not support InstallModeType OwnNamespace - OpenShift Pipelines. That's not a big deal as it resides in its own namespace. General idea seems to be technically feasible.
On the other hand - what if we flip the behavior a bit. Instead of using latest version of everything on the target environment, we can ensure (CI&CD) that whatever "latest" release we produce, it has the latest components - but components at a fixed version. This way we'll ensure the things are reasonably fresh while not risking unexpected updates during the course itself.
If possible, lets see if we can deploy all operators to their own namespaces.
That way, if a breaking change happens in an operator (as it did with gitops operator 1.7.0) we could pin it to a Manual installed version very easily.
With many operators sharing the openshift-operator namespace, becomes a lot harder to do this as every operator in the namespace would need to be Manual if one is (linked to the OG/OLM)
The dependency here will be if individual operators support this capability (many do).
The text was updated successfully, but these errors were encountered: