Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Server side apply creates#1995

shawkins started this conversation inGeneral
Aug 4, 2023· 1 comments· 5 replies
Discussion options

shawkins
Aug 4, 2023
Collaborator

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

You must be logged in to vote

Replies: 1 comment 5 replies

Comment options

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.

You must be logged in to vote
5 replies
@shawkins
Comment options

shawkinsAug 4, 2023
Collaborator Author

unlike the admin Secret in Keycloak

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

@shawkins
Comment options

shawkinsAug 4, 2023
Collaborator Author

@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
Comment options

It makes sense to me to have this configurable. 👍

@csviri
Comment options

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
Comment options

@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.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
General
Labels
None yet
3 participants
@shawkins@csviri@vmuzikar

[8]ページ先頭

©2009-2025 Movatter.jp