Repository navigation
Labels
area/operatorKeycloak Operator — Kubernetes/OpenShift deployment, CRDs, Helm chartsKeycloak Operator — Kubernetes/OpenShift deployment, CRDs, Helm chartskind/bugCategorizes a PR related to a bugCategorizes a PR related to a bugpriority/blockerHighest Priority. Has a deadline and it blocks other tasksHighest Priority. Has a deadline and it blocks other tasksrelease/26.6.2release/26.7.0team/cloud-nativeteam/communityteam/continuous-deliveryteam/core-authnteam/core-clientsteam/core-iamteam/core-protocolsteam/core-sharedteam/production-readinessteam/security
Milestone
Description
Before reporting an issue
- I have read and understood the above terms for submitting issues, and I understand that my issue may be closed without action if I do not follow them.
Area
operator
Describe the bug
After upgrading via OLM on OpenShift 4.20 the keycloak operator failed to upgrade the keycloak instance and almost all resources managed by the operator needed to be deleted.
The operator printed errors like this for all resources:
Caused by: io.fabric8.kubernetes.client.KubernetesClientException: Failure executing: PATCH at: https://...:443/api/v1/namespaces/keycloak/services/keycloak-service?fieldManager=keycloakcontroller&force=true. Message: Operation cannot be fulfilled on services "keycloak-service": the object has been modified; please apply your changes to the latest version and try again. Received status: Status(apiVersion=v1, code=409, details=StatusDetails(causes=[], group=null, kind=services, name=keycloak-service, retryAfterSeconds=null, uid=null, additionalProperties={}), kind=Status, message=Operation cannot be fulfilled on services "keycloak-service": the object has been modified; please apply your changes to the latest version and try again, metadata=ListMeta(_continue=null, remainingItemCount=null, resourceVersion=null, selfLink=null, additionalProperties={}), reason=Conflict, status=Failure, additionalProperties={}).
Version
26.6.0
Regression
- The issue is a regression
Expected behavior
The operator updates the instance.
Actual behavior
The operator does nothing and prints errors.
How to Reproduce?
Update a keycloak instance. It might be of note that this keycloak resource is over 3 years old.
Anything else?
No response
Reacted by ssams, Tobias Genannt, Alexis Rico and Frank Sauerburger
Reacted by Omar El Oubari
Metadata
Metadata
Assignees
Labels
area/operatorKeycloak Operator — Kubernetes/OpenShift deployment, CRDs, Helm chartsKeycloak Operator — Kubernetes/OpenShift deployment, CRDs, Helm chartskind/bugCategorizes a PR related to a bugCategorizes a PR related to a bugpriority/blockerHighest Priority. Has a deadline and it blocks other tasksHighest Priority. Has a deadline and it blocks other tasksrelease/26.6.2release/26.7.0team/cloud-nativeteam/communityteam/continuous-deliveryteam/core-authnteam/core-clientsteam/core-iamteam/core-protocolsteam/core-sharedteam/production-readinessteam/security
Type
Fields
No fields configured for bug.
Activity
pjoomen commentedon Apr 17, 2026
This seems to be caused by the
ownerReferencesof the resources specifyingk8s.keycloak.org/v2alpha1. Updating those tok8s.keycloak.org/v2beta1is a functioning workaround for this issue.This is the case for the following resources:
keycloak/keycloak-serviceservice/keycloak-discoverysecret/keycloak-initial-adminnetworkpolicy/keycloak-network-policysts/keycloakshawkins commentedon Apr 17, 2026
@pjoomen @bo0ts my expecation was that the josdk would automatically update the references on the next reconciliation, but it appears instead it's attempting to do creates which results in a conflict.
Let me see if we need to take responsibility for this in our operator for now.
shawkins commentedon Apr 17, 2026
@csviri @metacosm the default ownerReference matching does not appear to be version tolerant. I'm thinking about working around this with https://github.com/keycloak/keycloak/pull/48213/changes#diff-18c4f9baca7371de446e393c9d273e0af2a45afbceab222c10d7d11fead60671R40 - can you comment on if this is something the operator sdk should be handling automatically, or if it doesn't seem safe to relax this matching? My reasoning is that for a given api and kind there is only a single stored version, so it sdk shouldn't care for the purposes of matching.
14 remaining items
fix: ensures that owner references are updated after an upgrade (keyc…