-
Notifications
You must be signed in to change notification settings - Fork 218
Support for dynamic registration of EventSources #2120
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
Hi, Already started to work on that. For now I would suggest to use standalone dependent resources, and check with the client if the CRDs are present on the server, and only register those informers if they are. You can implement this logic directly in the EventSourceInitializer. Will close this issue as a duplicate if this is clear and no objections |
Hello @csviri , Thank you for the fast reply, it's really great news that this feature would be implemented soon! Just to clarify, we're using standalone dependent resources, because we have some logic in the If that is what you're intending to implement, then we're looking forward to that. Best Regards, |
@ivanchuchulski well what you suggest would be possible, although it is advised rather to have one informer (or as minimal number as possible) per type, so if you register informer per resource that might result in lots of informers therefor lots of websocket connections - what might not be desirable. In terms of dependent resource scope we out of the box will support case when we have a resource where this mentioed activation condition holds will register the informers, but not per resources. So in other works, think of the use case, if the platform support certManager, will the whole workflow work with cert manager. But again, your use case will be also possible. |
Hi @csviri ,
Our use case is that we need a couple of As I'm not familiar with the low-level details of the framework abstractions, I don't know if there would be any drawback if we should convert to the usage of one event source per resource type and how to implement that correctly. |
@ivanchuchulski here you can find links to samples in docs: So share the event source. |
Hello,
We are migrating a Helm Chart to Operator based provisioning of an application. Our application should have the ability to work either with native K8s Ingress or with Istio service mesh. We're using standalone dependent resources in our reconciler and we register the event sources, by implementing the
EventSourceInitializer<T>
and theprepareEventSources
method, where we call the staticEventSourceInitializer.nameEventSourcesFromDependentResource()
method and passing an array, which we create beforehand, containing instances of our needed dependent resources. In that array, currently we put a couple of Istio specific resources, likeVirtualService
andGateway
, for which we had to add the Istio client artifact to get the object definitions.However, we if we try to start the Operator in a cluster, that hasn't got Istio installed, we get an error:
which leaves the operator not able to process any further data.
Correct me if I'm wrong, but I believe this error is happening, because the
Informers
of theDependentResource
'sEventSources
, created in theprepareEventSources
aren't able to query Istio resource APIs, which aren't present in the API server, since their CRD definitions are missing.Do you have any suggestion how to resolve this issue? Is there a mechanism, which would allow us to somehow change dynamically the set of
EventSource
s, which are associated with a given reconciler?Best Regards,
Ivan
The text was updated successfully, but these errors were encountered: