Possibility to create DependentResources via custom Factory

[nsoubelet]

Hello,
I have a pretty specific use case for which I would like to have a KubernetesDependentResource with a constructor over which I need to pass certain parameters.
I noticed there is a DependentResourceFactory interface but seems to be used internally and not meant to be specified by implementors (Controllers).

This is what I need to achieve:

public class MyDeleterBulkPods
        extends
        KubernetesDependentResource<Pod, MyResource>
        implements
        Creator<Pod, MyResource>,
        Updater<Pod, MyResource>,
        Deleter<MyResource>,
        BulkDependentResource<Pod, MyResource> {

     public MyDeleterBulkPods(param1, param2....) {
        super(Pod.class);
        ... internal setup
    }

}

public class CRUDPodsBulkDependentResource extends MyDeleterBulkPods
    implements GarbageCollected<MyResource> {

    public CRUDPodsBulkDependentResource(param1, param2....) {
        super(param1, param2....);
        ... internal setup
    }

}

>> Controller has...
@ControllerConfiguration(
        dependents = @Dependent(type = CRUDPodsBulkDependentResource.class))

I think that implementation should not be difficult, a possible flexible way, which may be the base for bigger features like injection in Spring or any other Jakarta-CDI-based framework like Quarkus, is by recognizing dynamically whether a @Dependent type is an actual DependentResource or a delegate (factory).
In that approach, we could decide in method instantiateAndConfigureIfNeeded whether create the instance locally or delegate it.

Could be something like:

@ControllerConfiguration(        
        dependents = @Dependent( type = DR.class, strategy = Strategies.DELEGATE ), @Dependent( type = DR2.class, strategy = Strategies.DELEGATE ))
public class MyController
        implements
        DependentResourcesFactory,
        Reconciler<MyCustomResource>,
        Cleaner<MyCustomResource>,
        ResourceEventAware<MyCustomResource> {

...

	DependentResource createFrom(DependentResourceSpec spec, C configuration) {
                ... logic for determining what type we need to create
                if (spec.getDependentResourceClass() ...);
		  return new DR(param1, param2,....)
               ... etc
	}

}

Hope I made myself clear, if not please comment!

Thanks in advanced

[csviri]

Hi @nsoubelet ,

after our initial discussion, was thinking that, this should be actually possible with custom configurations, this is not a very good documented feature, will add docs and sample integration test. But it should be possible as shown here:

Define a custom configuration for the dependent resource:

https://github.com/java-operator-sdk/java-operator-sdk/blob/main/operator-framework/src/test/java/io/javaoperatorsdk/operator/config/BaseConfigurationServiceTest.java#L412-L412

You can override the config values as shown here:

https://github.com/java-operator-sdk/java-operator-sdk/blob/main/operator-framework/src/test/java/io/javaoperatorsdk/operator/config/BaseConfigurationServiceTest.java#L412-L412

Is this good enough for you?

[nsoubelet]

Hi @csviri
Thanks for your comments. I saw that option when exploring the code, but did not get entirely the idea of how it works to be honest, however, as you suggested, I'll give a try.

In the meantime, what I did is what you suggested yesterday which is use the standalone approach and call DR's reconcile during controller's reconciliation, as shown in StandaloneBulkDependentReconciler sample.

What I suggested in the ticket is having different strategies for DR instantiation, which could be the base for having delegates that look up within a context, for example. I guess that could be easier to read and follow the code and to adapt to different frameworks.

Btw, nice lib guys! I love it, great work :)

[csviri]

What I suggested in the ticket is having different strategies for DR instantiation, which could be the base for having delegates that look up within a context, for example. I guess that could be easier to read and follow the code and to adapt to different frameworks.

Yes this is definetelly we should look into it.

thank you!

cc @metacosm

[metacosm]

I'm not sure about all that was discussed but the Quarkus extension already makes use of the DependentResourceFactory interface by providing a tailored implementation that actually looks up the dependent resource implementations among available CDI beans (in the Quarkus extension, all dependent resources are CDI beans). As you justly mentioned, this interface is not really meant for external consumption and replacing the implementation provided by the ConfigurationService that the framework flavour is using might cause issues: for example, using a different factory in Quarkus would probably break the integration.

[nsoubelet]

Hi @metacosm, I was not aware.
In this particular case I'm using SpringBoot, but I will take a look to see how it is implemented for Quarkus, concept and strategy should be the same.

[metacosm]

That said, it might be beneficial to maybe clean this up a little bit and make it part of the documented API since this should indeed help for framework integration.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.