Question for 5.2 migration

[jonesbusy]

Hi,

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

I have multiple Kubernetes Bulk dependent defined as

public class TeamSyncBulkDependent extends KubernetesDependentResource<CloudTeam, CloudTeamSync>
        implements CRUDBulkDependentResource<CloudTeam, CloudTeamSync> {

   // desiredResources and getSecondaryResources implemented here

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

public class TeamSyncBulkDependent extends KubernetesDependentResource<CloudTeam, CloudTeamSync>
        implements CRUDBulkDependentResource<CloudTeam, CloudTeamSync, String> {

But then I'm force to implement the following

    @Override
    public void deleteTargetResource(
            CloudTeamSync primary, CloudTeam resource, String s, 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

    @Override
    public void deleteTargetResource(
            CloudTeamSync primary, CloudTeam resource, String s, Context<CloudTeamSync> context) {
        context.getClient().resource(resource).delete();
    }

Thanks for the help!

[csviri]

Hi @jonesbusy

there is a prepared CRUDKubernetesBulkDependentResource

That uses ResourceID (not string) for you.

[jonesbusy]

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

    return context
        .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)

[jonesbusy]

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

I was not using the Updater but only the Creator and Deleter traits

Before 5.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 implement Updater interface (which is totally logic and works well, I was probably doing it wrong before).

Is it possible that previous behavior the Updater 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)