`SharedInformerFactory.inNamespace()` deprecated without an equivalent alternative

[adriansuarez]

Is your enhancement related to a problem? Please describe

The Javadoc for SharedInformerFactory.inNamespace() says to use the Informable interface. But shared informers created through the Informable interface are not accessible using SharedInformerFactory.getExistingSharedInformer().

I'm not sure why namespace-scoped shared informers should not be managed by the SharedInformerFactory.

Anyone who is creating namespace-scoped informers using the SharedInformerFactory and is relying on the factory as a registry for shared informers will have to create their own registry and manage the lifecycle of the shared informer themselves. That is more work than just changing the method that is being invoked.

Describe the solution you'd like

Remove the @Deprecated annotation from SharedInformerFactory.inNamespace(). I'm assuming that the @Deprecated annotation means that the method will be removed in a future release, but I don't think it should be removed for the reason above.

Describe alternatives you've considered

No response

Additional context

No response

[shawkins]

Remove the @deprecated annotation from SharedInformerFactory.inNamespace(). I'm assuming that the @deprecated annotation means that the method will be removed in a future release, but I don't think it should be removed for the reason above.

SharedInformerFactory is not a good abstraction:

• You may configure informers for more than just names and namespaces - in particular labels.
• The SharedInformerFactory only tracks informers by type, which is limiting and confusing. For example:

factory.inNamespace("x").sharedIndexInformerFor(clazz, 0);
...
factory.getExistingSharedIndexInformer(clazz); // returns an informer in namespace x

If instead I do:

factory.sharedIndexInformerFor(clazz, 0);
...
factory.inNamespace("x").getExistingSharedIndexInformer(clazz); // returns an informer watching all namespaces

In other words you need intimate knowledge about the circumstances under which the first instance of an informer of type clazz was created to know that you can successfully reuse it.

Rather than investing more time into this abstraction it seems better to just let developers use their own intimate knowledge about what the purpose of each informer they create is and yes handle a registry for that if needed. The java operator sdk has facilities for this if you are doing operator development.

[adriansuarez]

I did notice that SharedInformerFactory.inNamespace() mutates the factory rather than returning a new object that causes the namespace to be injected somehow. Should the entire SharedInformerFactory be deprecated based on the limitations that you mentioned?

I don't think that these limitations are that bad, and the surprising behavior associated with inNamespace() could be resolved by just replacing it with a non-chainable setNamespace() method that makes it clear that the factory is being reconfigured.

[shawkins]

Should the entire SharedInformerFactory be deprecated based on the limitations that you mentioned?

The class was added for compatibility with https://pkg.go.dev/k8s.io/client-go/informers#SharedInformerFactory - but note there that the namespace is an argument to create the factory.

I don't think that these limitations are that bad, and the surprising behavior associated with inNamespace() could be resolved by just replacing it with a non-chainable setNamespace() method that makes it clear that the factory is being reconfigured.

Unfortunately setNamespace is even worse - you still need the same intimate knowledge around how the first informer of type clazz was created. inNamespace could be changed / documented as returning a new factory, but I'd still prefer to remove it.