Managed BulkDependentResource fails with reconcilePrecondition

[grawinkel]

Bug Report

On Operator SDK 4.2.0 (commit: 061db9c):

I want to implement a Resource

public class SomeResourceDependentResource extends CRUDKubernetesDependentResource<X, Y>
    implements BulkDependentResource<X, Y>
{
... desiredResources(...)
... getSecondaryResources(...)
}

And use it as a Managed Resource with a reconcilePrecondition

@ControllerConfiguration(
    dependents = {
        @Dependent(
            name = "SomeResource",
            type = SomeResourceDependentResource.class
            reconcilePrecondition = SomePrecondition.class
            ),
    })

As soon as the reconcilePrecondition is configured, the SomeResourceDependentResource fails, since it is not handled as a BulkDependentResource but as a normal DependentReousource. So the getSecondaryResource() is called, instead the getSecondaryResources(), which leads to errors.

What did you expect to see?

Being able to use reconcilePrecondition with BulkDependentResource.

[csviri]

Thanks @grawinkel for reporting this, will take a look.

[csviri]

On Operator SDK 4.2.0 (commit: 061db9c):

I can't see how this is related tbh.

[csviri]

The problem is with condition API, at some point we added there the resource created by the dependent resource, that is clearly not fitting in this case.

https://github.com/java-operator-sdk/java-operator-sdk/blob/d83b9f817fe79c81b4601c41401058b57492b41e/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/dependent/workflow/Condition.java#L20-L20

So we probably need to pass here the dependent resource not the resource. So then the user will can decide, which method to call. Will create a issue for that to discuss.

For now it can be handled in the PR, so the resource in the condition will be a Map of resources:

public class SamplePrecondition
    implements Condition<Map<String, ConfigMap>, BulkDependentTestCustomResource> {

  @Override
  public boolean isMet(BulkDependentTestCustomResource primary, Map<String, ConfigMap> secondary,
      Context<BulkDependentTestCustomResource> context) {
    // ...
  }
}

But I see this more like a workaround. The API would be nicer with the dependendent resource as a parameter.

[csviri]

created issue: #1689