Replies: 1 comment 15 replies
-
|
@shawkins Does this capture all we've talked about? |
Beta Was this translation helpful? Give feedback.
15 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
The problem
Currently, we support installing the Operator only in the namespaced mode, i.e. to deploy Keycloak in a namespace, an Operator instance needs to live in the same namespace. This is problematic for a couple of reasons:
The solution: Cluster-wide Operator
With cluster-wide Operator, there can be a single Operator instance for the whole cluster, managing all Keycloak instances in all namespaces.
Considerations
Proposed plan
Milestone 1: basic MVP, supporting a single Keycloak version
To resolve majority of the issues and satisfy the demand from users for the cluster-wide Operator as quickly as possible, we'd expose the cluster-wide mode and document it. It is already implemented and handled by JOSDK but it is hidden in the Keycloak Operator.
The caveat here would be everything mentioned above in "Considerations". Those would need to be explicitly documented. The most prominent limitation would be the 1:1 version mapping of the Operator and Keycloak. Hence, the feature would be marked just as a Preview.
Estimated effort: low. We're just exposing already implemented functionality. What is missing is some basic tests, and docs.
Milestone 2: supporting Keycloak version range
As the next step, a single Operator version would support all Keycloak versions for the same major release. E.g. Operator version 27.3 would support Keycloaks 27.0, ..., 27.3, 27.4, ... 27.8, etc.
This would require the Operator to check the Keycloak version, or possibly better: the enabled features versions. This would cover the scenarios when newer Operator is used with older Keycloak – the Operator would disable some of its features that require features enabled at the Keycloak side. Version awareness would also help with the "rolling updates" consideration – Operator would keep the original fields on the deployment based on the Keycloak version, not Operator version.
Forward compatibility (older Operator, newer Keycloak) is ensured implicitly – we don't introduce breaking changes to Keycloak in minor releases.
Estimated effort: high. We'd need to introduce a mechanism for fetching versioning metadata from Keycloak. Additionally, if features were considered as well, we might need to wait for the future refinement of our features story.
Related
Beta Was this translation helpful? Give feedback.
All reactions