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

Question for 5.2 migration#3086

jonesbusy started this conversation inGeneral
Dec 6, 2025· 2 comments· 3 replies
Discussion options

Hi,

I understand that the 5.2 has some breaking changes, but it's not clear in my situation (Even after readinghttps://javaoperatorsdk.io/docs/migration/v5-2-migration/)

I have multiple Kubernetes Bulk dependent defined as

publicclassTeamSyncBulkDependentextendsKubernetesDependentResource<CloudTeam,CloudTeamSync>implementsCRUDBulkDependentResource<CloudTeam,CloudTeamSync> {// desiredResources and getSecondaryResources implemented here

After 5.2 migration I understand I need to pass a String resource ID

publicclassTeamSyncBulkDependentextendsKubernetesDependentResource<CloudTeam,CloudTeamSync>implementsCRUDBulkDependentResource<CloudTeam,CloudTeamSync,String> {

But then I'm force to implement the following

@OverridepublicvoiddeleteTargetResource(CloudTeamSyncprimary,CloudTeamresource,Strings,Context<CloudTeamSync>context) {//    }

I'm not sure if I'm missing something on the class hierarchy but I don't need to change anything related to delete behavior of dependent

I guess one of the solution is to implement

@OverridepublicvoiddeleteTargetResource(CloudTeamSyncprimary,CloudTeamresource,Strings,Context<CloudTeamSync>context) {context.getClient().resource(resource).delete();    }

Thanks for the help!

You must be logged in to vote

Replies: 2 comments 3 replies

Comment options

Hi@jonesbusy

there is a preparedCRUDKubernetesBulkDependentResource

That uses ResourceID (not string) for you.

You must be logged in to vote
2 replies
@jonesbusy
Comment options

Thanks. But I think I will not be able to "migrate" from the String mapping to ResourceID

I'm using String mapping everywhere for BulkResource

Map<String, MyCR> desiredResources(...)public Map<String, MyCR> getSecondaryResources(...)

i tried something like

returncontext        .getSecondaryResourcesAsStream(MyCR.class)        .filter(cm ->getName(cm).startsWith(primary.getMetadata().getName()))        .collect(Collectors.toMap(ResourceID::fromResource,Function.identity()));

But many upgrade attempt cause all my CR dependent to be recreated (I guess none of the ID matches)

@csviri
Comment options

Could you provide pls a simplistic reproducer for this? Will take a look what if any goes wrong.
Does youMyCR implements equals?

Comment options

An other point that I noted (And that I don't fully understand) after adding theResourceIDProvider<String> to many external resource is that they were not updated (create + delete works well).

I was not using theUpdater but only theCreator andDeleter traits

Before5.2.0 the create method was called when the desired state of the resource didn't the actual state (from the fetch) This was ok for my case because it was idempotent

Now I'm force to implementUpdater interface (which is totally logic and works well, I was probably doing it wrong before).

Is it possible that previous behavior theUpdater was superflous for external resource? How the "ID" was handled in the case? (I guess using hashCode/equals?)

Thanks or the hints (this help me understand better the upgrade)

You must be logged in to vote
1 reply
@csviri
Comment options

Hi yes, the external resource handling had some issues before, now it should be ok with the design from 5.2. Before 5.2 (and after 5.0) there was not nice way to select and the target resource from multiple dependent resources and also check for equality; that could lead to all kind of issues if you did not override some methods. But with the current design it should be ok.

see details here:#2972

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

[8]ページ先頭

©2009-2025 Movatter.jp