do we really think that a user will configure a scheduler without registering the volume-based plugins? I feel that those should be treated the same as pod and node.

do we really think that a user will configure a scheduler without registering the volume-based plugins?

Nope, I think volume-based plugins are always needed. The design intention is that they're not interacting with internal cache (but pod and node do), so they fit the switch case naturally, to leverage buildEvtResHandler generaizing their event handler instantiation.

We could have buildEvtResHandler function moved outside, so we can still reuse it. The way I am interpreting this switch statement is whether or not those events are necessary to register. If we are saying the storage based ones should always be registered, then I think it is better to treat them like pod/node.

(missed this comment earlier)

Another benefit is that we can generalize the registration for add/update/delete events dynamically - for example, currently storage-related registrations are hard-coded, some register add/update, some register add, etc. But if we leverage the unioned cluster events, we can dynamically register the event handlers - which will be resilient to adapt to further code changes such as add/delete events. WDYT?

is there any overhead (specifically memory and traffic between the api-server and scheduler) to instantiating this informer? if so, we should have an explicit enable flag in component config that is false by default.

In terms of default scheduler, there is no plugin registering CR events, so IMO instantiating a dynInformerFactory won't do any concrete work.

so the dynamic informer cache is populated only if an event is registered?

yes, just like coreInformerFactory, by default the embedded informers are empty.

hmm, so someone needs to initiate an informer then, so that makes it even more necessary to pass this factory via framework handler to the plugins that will use it, right?

Yes, that's your point at #101394 (comment). For now, plugin developers instantiate typed informer and register event handlers accordingly.

It is related, but might be different. If you remember, an informer is initiated only if it is explicitly accessed before starting the the informer. Is this the case here (I don't have experience with dynamic informer, so asking just to make sure)?

If you remember, an informer is initiated only if it is explicitly accessed before starting the the informer.

Yes, similar here. For dynamic informer factory, an informer for CR xyz is only initiated when we fetch the gvr of xyz, and call its informer() function. In this PR, it's in the default case - i.e., only triggered when a custom plugin implemented EventsToRegister() to show its interests in CR xyz.

However, the framework doesn't really care about the cache for CRs - the out-of-tree plugins are responsible to build their own cache, if needed. The hook setup here is fairly simple: just to guarantee that upon some CR events, partial unschedulable Pods can be moved properly.

(BTW: I rethink the necessity of offering the dynInformerFactory in framework handle. See my other comment #101394 (comment))

if plugins want to access CRD resources, it is better if they do through the same informer factory used for registering the events, so we may want to plumb this to the framework handler just like we did for shared informer factory.

Good point. I need to think about it. I'm a bit concerned that would add extra burden for plugin developers, such as fetching the GVR before add event handlers, etc. Probably need to compare it with how controller-runtime obstacles similar problems, and come up with a better abstraction.

I rethink it a bit. It's better not to enforce out-of-tree plugins to use dynamic informers as typed ones are more applicable and easy to manipulate, in both core logic and tests.

We are not forcing them to use it, but I think it is useful to make it available to them since the cache is already populated for the types they registered events for. If they create there own informer for the same type, aren't we wasting memory because we will have two informerFactor caches?

but I think it is useful to make it available to them since the cache is already populated for the types they registered events for

Not quite sure the plugin developers would really use it, as the typed informer and other generated stuff are way easier to manipulate and performant.

If they create their own informer for the same type, aren't we wasting memory because we will have two informerFactory caches?

Yes, this is true. But AFAIK, using dynamic client/informer all the way down can impose overhead as it stores objects as interfaces under the hood, and hence that cause a lot of reflection operations.