[Question] Consuming From another Operator

[salaboy]

Describe the problem:

The problem is, I have two

@Operator(forKind = ServiceA.class, prefix = "salaboy.org")

and

@Operator(forKind = ServiceB.class, prefix = "salaboy.org")

From Service A onAdd(ServiceA serviceA) I want get check all the instances of ServiceB.
It feels to me that then I need to register manually a Fabric8 Kube APIs watch on a Custom Resource, which push me to do all the manual handling instead of reusing the ServiceB operator.

Steps to reproduce:

Observed Results:

• What happened? This could be a description, log output, etc.

Expected Results:

It will be great if the AbstractOperator provide a client for fetching those resources. By a Client I mean:

private NonNamespaceOperation<ServiceA, ServiceAList, DoneableServiceA, Resource<ServiceA, DoneableServiceA>> serviceACRDClient;

If this exists.. maybe some pointers to the docs would help

[jkremser]

do I get it right that you want to be notified in onAdd(A a) when Bs are being "CRUDed"? Or you just need a way to read all the Bs from that onAdd(A a) method, because there is some 1:n relationship between A and B?

For the latter use-case the AbstractOperator.getDesiredSet() could work. However, I like your suggestion to expose that crd client to provide even more flexibility. Would that be something you would like to implement and send PR?

[salaboy]

@Jiri-Kremser thanks for the response and yes... I was looking for that exact use case "you just need a way to read all the Bs from that onAdd(A a) method, because there is some 1:n relationship between A and B?"

It will be great to add Spring Boot support for auto configs.. so I can auto wire one Operator into another and then do List as = operatorA.getResources();

I can create a PR.. but the main problem that I see is the leaking of the Fabric8 types to the consume. I like the way that you guys abstracted all the Doneable things from the Fabric8 client.. I would like to keep it that way..

[salaboy]

@jkremser is there any way to get in touch to have a chat besides GitHub? I want to contribute back but I need to have the answer to some questions before.

[jkremser]

@salaboy we can use an ad hoc channel #spark-operator@freenode

[frbl]

@salaboy , is this something you've been working on already? It indeed sounds very useful.

[frbl]

@jkremser you mentioned:

do I get it right that you want to be notified in onAdd(A a) when Bs are being "CRUDed"

What if that is indeed what we want? Is there an implementation for that already?

[frbl]

we want to start with extending the sdk such that operators listening on CRD A kinds can also respond to changes in CRD B kinds. E.g., if a new version of B is deployed, we might also want to deploy a new version of A. would that also suit your use-cases?

[jkremser]

I haven't met the need for this yet, however this seems reasonable for use cases w/ dependency between A and B. Please contribute back :)

[frbl]

We will! actually a colleague of mine shortly talked to you after the Spark summit in Amsterdam. Would you mind a quick call / skype session to get us up to speed, and see how we can best contribute?

[metacosm]

@jkremser I've started investigating this. However, I'm wondering if it would make sense to split the handling of ConfigMaps vs. Custom Resources. Is there really a need to be able whether to use CMs or CRs at runtime (in particular via env variable)? I've started separating the code but I wanted to know if you thought it made sense. Separating the code would make it easier to add additional features for dependent resources (i.e. when there are dependencies between CRs and/or base k8s resources). See https://github.com/metacosm/abstract-operator/tree/split-cr-cm.

[jkremser]

@frbl pls send me an email and we can talk the details (jiri.kremser@gmail.com)

@metacosm "CM-mode vs CR-mode in runtime" nope, there isn't CRs was the first shot and it was basically a workaround for the OpenShift restricted rights for normal users. These days the CRDs should be the default and any other k8s object should be also supported.

yea, it's probably cleaner that way you have it and it would allow for the extensibility for the base k8s resources (pod/deployment/job..). Contributions are welcome 💯