Repository navigation
fix: document having multiple operators installed - #33448
Conversation
closes: keycloak#32152 Signed-off-by: Steve Hawkins <shawkins@redhat.co 8000 m>
| - CRD revisions from newer Operator versions won't introduce breaking changes except for the eventual removal of fields that have been well deprecated. Thus newer CRDs are generally backward compatible. | ||
| - the CRDs installed last will be the ones in use. | ||
| - older CRDs may not be forwards compatible with new fields used by newer operators. When using OLM it will check if your custom resources are compatible with the CRDs being installed, so the usage of new fields can prevent the simultaneous installation of older operator versions. | ||
| - fields introduced by newer CRDs will not be supported by older Operators. Older Operator will fail to handle such CRs with an error deserializing an unrecognized field. |
There was a problem hiding this comment.
Our CRs and CRDs currently do not make use of additionalProperties (like fabric8 built-in objects) - if they ever do, then this last point won't hold.
There was a problem hiding this comment.
I believe failing is a more appropriate handling of unrecognized fields in the Operator as it highlights a configuration error (user tries to use a configuration incompatible with used Operator version).
| - all Operators share the CRDs (Custom Resource Definitions) as they are installed cluster wide. | ||
| - CRD revisions from newer Operator versions won't introduce breaking changes except for the eventual removal of fields that have been well deprecated. Thus newer CRDs are generally backward compatible. | ||
| - the CRDs installed last will be the ones in use. | ||
| - older CRDs may not be forwards compatible with new fields used by newer operators. When using OLM it will check if your custom resources are compatible with the CRDs being installed, so the usage of new fields can prevent the simultaneous installation of older operator versions. |
There was a problem hiding this comment.
| - older CRDs may not be forwards compatible with new fields used by newer operators. When using OLM it will check if your custom resources are compatible with the CRDs being installed, so the usage of new fields can prevent the simultaneous installation of older operator versions. | |
| - older CRDs may not be forwards compatible with new fields used by newer operators. When using OLM it will check if your custom resources are compatible with the CRDs being installed, so the usage of new fields can prevent the simultaneous installation of older operator versions. In that case you first need to install the older Operator version and then the newer one that introduces new fields to the CRDs. |
There was a problem hiding this comment.
@vmuzikar This note is less about the initial install of an older version, and more about where the user already has two versions of the operator and the older one is eligible for a fix release. Any usage of a new CRD field will then block the ability to upgrade the older one. I don't think we have a good / well supported mechanism for that.
There was a problem hiding this comment.
Yeah, that's a good point. I didn't realize the upgrades. This behaviour sucks more than I thought. I think the proper solution would be the cluster-wide Operator. As you suggested somewhere else, an alternative might also be to release the CRDs as an individual bundle but that feels more like a potentially confusing workaround to me.
There was a problem hiding this comment.
Right. We do also have the option of exposing our cluster wide support, but just document it as preview...
There was a problem hiding this comment.
@shawkins We'd need to first figure out our support matrix and also how to communicate to users which fields are supported with which Keycloak versions.
There was a problem hiding this comment.
The cluster wide support doesn't need to have those kinds of problems - if we simply follow the leader and remove the unsupported fields from the CRDs when support is dropped, then the users will be blocked from migrating to that version until they have dealt with the removal. However there needs to be an inbetween release that has both old and new support - which is what we're breaking wrt to hostname v1 and product users.
Obviously that runs afoul of blast radius concerns, but that is quite complex to address.
Co-authored-by: Václav Muzikář <vaclav@muzikari.cz> Signed-off-by: Steven Hawkins <shawkins@redhat.com>
Co-authored-by: Václav Muzikář <vaclav@muzikari.cz> Signed-off-by: Steven Hawkins <shawkins@redhat.com>
* fix: document having multiple operators installed closes: keycloak#32152 Signed-off-by: Steve Hawkins <shawkins@redhat.com> * Update docs/guides/operator/installation.adoc Co-authored-by: Václav Muzikář <vaclav@muzikari.cz> Signed-off-by: Steven Hawkins <shawkins@redhat.com> * Update docs/guides/operator/installation.adoc Co-authored-by: Václav Muzikář <vaclav@muzikari.cz> Signed-off-by: Steven Hawkins <shawkins@redhat.com> --------- Signed-off-by: Steve Hawkins <shawkins@redhat.com> Signed-off-by: Steven Hawkins <shawkins@redhat.com> Co-authored-by: Václav Muzikář <vaclav@muzikari.cz> (cherry picked from commit 9fb187c)
* fix: document having multiple operators installed closes: #32152 Signed-off-by: Steve Hawkins <shawkins@redhat.com> * Update docs/guides/operator/installation.adoc Co-authored-by: Václav Muzikář <vaclav@muzikari.cz> Signed-off-by: Steven Hawkins <shawkins@redhat.com> * Update docs/guides/operator/installation.adoc Co-authored-by: Václav Muzikář <vaclav@muzikari.cz> Signed-off-by: Steven Hawkins <shawkins@redhat.com> --------- Signed-off-by: Steve Hawkins <shawkins@redhat.com> Signed-off-by: Steven Hawkins <shawkins@redhat.com> Co-authored-by: Václav Muzikář <vaclav@muzikari.cz> (cherry picked from commit 9fb187c)
closes: #32152