Repository navigation
Replies: 1 comment
|
We do our configuration change documentation for k8s cluster deployment by committing the helm values to git. This applies to the initial realm configuration too. Because the realm configuration is part of the helm values. Why you couldn't pursue the "code first" approach at this point? |
0 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.
Uh oh!
There was an error while loading. Please reload this page.
The new operator, as well as the old one (Keycloak Realm Operator) can handle realm imports, but only imports. Any new changes made to the related custom resources are "ignored" unless the user deletes the affected realm in beforehand.
Is it planned to keep realms in sync even after being imported? It would be really nice to have because for instance, if you have a user federation with users who have assigned roles, and you need to update the realm, they can stay in the realm. At the operators' current state, one has to rely on imports and has to make sure to backup these user data before deleting the realm.
If yes: Is it possible to implement it somewhere for the time being? I guess it would be possible to implement it in the Keycloak Realm Operator. AFAIK, there's no plan in create new CRDs in the new operator until Keycloak uses new Store.X mechanism? However, the KeycloakRealm CRD in the Realm Operator seems to be outdated, and I don't know if it's worth modifying these CRDs.
All reactions