Repository navigation
Improved Event Source Management For Dependent Resources #2285
Description
If there are multiple dependents for the same type they usually share event sources. Well in general we require that if event there are two Event Sources registered for the same type they manage a distinct set of resources.
See sample:
If they anyway share most of the cases with the Event Sources, we could handle this similarly as for the dynamically registered resources, if we make the resource named as described in this issue the Dependent Resource could name the event source by default based on it's type. (Like it will return ConfigMap as the name for InformerEventSource for a ConfigMap), thus if multiple Dependent Resources return the same event source with the same name it will just register one those.
The only problem is that those event sources theoretically can have different configuration. Currently this can be event configured with an annotation, see @KubernetesDependent, but if we could say that every Event Source has a configuration, that could be compared (and error thrown if those are not the same).
See also: #1937 (note that this issue is more radical than just comparing the configurations)
Activity
csviri commentedon Apr 11, 2024
See also: #1937 and #2123
Will try to summarize it here, what are the related questions/dilemmas to these 3 issues.
So we want to achieve:
useEventSourceWithName.getSecondaryResource(Class<R> expectedType, String eventSourceName);thus to get the resource by specifying the event source name. The reason is that, it is kinda assumption that even if there are multiple event sources for same type, they need could be distinct, although this might be a too strong assumption, we could have two informers with different label selectors, but those 2 sets of resources are not necessarily distinct - this why I still lean towards keeping the name and also make the configs (or directly the event sources) comparable.Here comes the picture of the configuration, we could say that two event sources are equal if their configuration is equal and they have the same type of course. But what happens if a DR provides an ES with a different name but the same config as already registered? Should they just provide event sources, and we can check if there is already an event source with the same config? Or just a NamedEventSource, and double check if there is no event source with the same type and configuration.
I lean towards the latest:
EventSourceinterface will haveString getName()method.Not sure if we should have explicit config notion on the level of EventSource interface, maybe a specialized
equalsmethod, to compare the event source to other regardless of name, and that will inInformerEventSourcecompare configurations.We should probably add an ADR regarding this.
csviri commentedon Apr 29, 2024
After experimenting with the equality of Event Sources, we found that there are some caveats with implementations. When checking equality for InformerEventSource for example, we check the equality of all the config values, however, this is problematic for interfaces like
SecondaryToPrimaryMappersince those will need to explicitly implementequalsandhashCode, which is hard to enforce.So for now decided to stick with explicit event source setting.