@shawkins - I'm struggling with this change as after using the port name, the Operator can't update a custom Ingress which has only the port number specified. It then throws the error "cannot set both port name & port number".

What is the recommended way to handle this with server-side-apply? IMHO the Ingress is missing an annotation in the Go code of Kubernetes to make this work, and I've opened an upstream issue for that: kubernetes/kubernetes#125869

Still this won't solve my problem short term. So I wonder:

• Is there a simple fix for that?
• Should the Ingress be deleted and re-created in this case? Where would I put such code?
• Should I abandon this PR altogether? The initial trigger was to work around a bug in the nginx ingress, see field ingress.spec.defaultBackend.service.port.number is broken kubernetes/ingress-nginx#11517 were I don't know how many people it affects. At the same time the current code might fail if there is a custom ingress which uses a port name, and the Operator would then have a problem changing it to a port number.

Thanks!

I'm struggling with this change as after using the port name, the Operator can't update a custom Ingress which has only the port number specified. It then throws the error "cannot set both port name & port number".

I've logged upstream issues related to this, but for services. SSA does not use the same rules as merge patches, so it's easier for it to get in a situation where the patch is invalid.

Is there a simple fix for that?

Let me check.

Should the Ingress be deleted and re-created in this case? Where would I put such code?

Ideally not, but in some cases we don't have a choice - such as changing a immutable field like statefulset match labels.

If a regular merge patch will work, it would probably be just as easy to use an override to do that patch instead of deleting.

At the same time the current code might fail if there is a custom ingress which uses a port name, and the Operator would then have a problem changing it to a port number.

If the user creates the ingress and it lacks the owner reference for the operator, the operator will not manage it - if it has the same name as the managed ingress and the user has not turned off ingress handling in the keycloak cr, then we'll throw an exception when we try to create the managed version.

Let me check.

I committed a possible workaround to repeat the update as a regular patch.

@shawkins - thank you for your contribution. I've updated this PR to apply the client side work a bit more broader in a way that you suggested in your commit. I didn't want to catch all KubernetesClientExceptions as that seems to be a bit broad to me.

Please let me know your thoughts in a review, and also decide if someone else from the CND team should review it as well.

Thanks!

@shawkins - thank you for pointing me at the "code". I didn't know about it and it is a lot cleaner.

I've updated the commit. If the build is green, it should be ready for review.