Server side apply creates

[shawkins]

Just wanted to make sure we're all on the same page with the proposed behavior of the JOSDK moving forward - that is it will use a dummy resourceVersion on a SSA create to simulate the atomic affect of a regular create.

We had ultimately decided against this in keycloak, but it sound like we'll pick it up from the operator sdk instead.

The major con of this approach, which exists also for regular JOSDK creates, is that an existing resource that lacks an owner reference will block any further reconciliation util it is deleted or has an owner reference added.

@csviri @vmuzikar

[vmuzikar]

I think that for generic create operations (unlike the admin Secret in Keycloak) it might make more sense to block the reconciliation if a foreign resource exists. After all, as mentioned, this approach is aligned with the non-SSA create action.

[shawkins]

unlike the admin Secret in Keycloak

After this change https://github.com/operator-framework/java-operator-sdk/pull/1994/files#diff-aa20588ab4b1ff4f171a897d4042d1b055c02737b067d09aaeb9cfd770adf3a0R133 it will affect the admin Secret as well.

[shawkins]

@csviri also mentioned possibly making the action configurable - it could be one of "use existing" (as-is without adding an owner reference - the old KeycloakAdminSecret behavior), assume ownership (how the other KeyCloak OperatorManagedResources functioned), or fail.

[vmuzikar]

It makes sense to me to have this configurable. 👍

[csviri]

created an issue: #1999

before v5 there will be a small v4.5 release probably, if not objections / you don't require this earlier, it will be released only there.

[vmuzikar]

@csviri If that means #1994 and #1999 will be released together, that works for us. In any case, we're not targeting the switch to the dependent resources in Keycloak 22. It's for future 23.