Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question] Consuming From another Operator #50

Open
salaboy opened this issue May 27, 2019 · 11 comments
Open

[Question] Consuming From another Operator #50

salaboy opened this issue May 27, 2019 · 11 comments

Comments

@salaboy
Copy link

salaboy commented May 27, 2019

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
Copy link
Member

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
Copy link
Author

salaboy commented May 27, 2019

@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
Copy link
Author

salaboy commented Jul 25, 2019

@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
Copy link
Member

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

@frbl
Copy link

frbl commented Sep 16, 2019

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

@frbl
Copy link

frbl commented Sep 24, 2019

@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
Copy link

frbl commented Oct 29, 2019

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
Copy link
Member

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
Copy link

frbl commented Oct 31, 2019

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
Copy link

@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
Copy link
Member

@frbl pls send me an email and we can talk the details ([email protected])

@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 💯

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants