-
Notifications
You must be signed in to change notification settings - Fork 218
Option to limit CRs the operator watches #453
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
Comments
@metacosm I have some spare cycles this week so if you need any help on this feature , I'd be happy to take a stab |
@lburgazzoli This sounds awsome! |
Ideally, however we implement this, it should boil down to generating a
|
I don't know if a predicate would be the best approach as then it would filter events after we receive them, instead a label selector (or anything similar) would configure the watcher to only watch some resources I guess on quarkus a possible representation using properties could be:
or
|
Ah, right. Should we also filter on annotations?
I'd prefer the second option (which I think Quarkus supports out of the box, iirc). |
As far as I know, you can't use annotation to select objects, only labels can be used. |
Yep annotations are not indexed in etcd AFK, so we cannot filtern on them (at least efficiently). I particulary like the idea to the the filtering on server side (K8S API) if possible based on labels, this is much more efficient, then doing it with the predicate in the operator. Although it's limited to labels, so we might need both if we want to be generic and cover every use case. But maybe just start with labels? An interesting thing is that admission controllers can do this based on namespaces so namespace selector: Agree with @metacosm that this should be dynamically configurable. |
@metacosm @csviri I'm working on a POC for this issue so we can discuss about code and wonder if we could add some tests based on the KubernetesServer in addition to the mocked tests as it simplifies things a lot. |
I agree that we need to beef up our testing story and adding tests based on KubernetesServer would make sense to explore that space and see what we're missing in terms of testing support. |
Don't know much about that mock server, but worked with the one from kube builder - that was awsome (but its a real api server not really stubbing). For development purposes I'm happy personally with minukube / kind. Very happy to discuss this, maybe on weekly, improving tests is always a good thing :) |
We should be able to restrict what CRs an operator handles, as example, by using a selector:
This could be required when a canary deployment of operators is required so at certain point in time, there will be more than one operator running in a cluster each one is taking into account a subset of the CRs.
The text was updated successfully, but these errors were encountered: