[Feature Request/Question] Controller watch namespaces based on labels (and event sources)

[btlem]

Description

Based on the documentation, the controller is able to dynamically adjust the watched namespaces based on explicit namespace names (often provided through a config map or similar). A convenient extension to this would be able to watch namespaces based on the labels/annotations for a given namespace. I would be helpful if this was built into the machinery of the controller itself, so it could be controlled by some high level configuration

Motivation

Sometimes the creation of new namespaces that need to interact (be watched by) with the operator are done through workflows outside of the purview of the "operator admin". Currently, in order to ensure coverage of all namespaces, either (1) both workflows need to interact and inform the operator deployment when namespaces are added, or (2) the operator simply needs to watch all namespaces. This is where a third option, of only coordinating the appropriate labels would be beneficial

(Somewhat) Related Projects

https://github.com/kubernetes-sigs/hierarchical-namespaces/blob/master/docs/user-guide/concepts.md

Workarounds considered

Use the Kubernetes client itself to query for namespaces upon controller start, periodically poll for changes. Similarly, try to use some form of an Informer to get the same information

[csviri]

Hi,
The Idea with the current implementation is that allows custom use cases.
So to implement this you can simply register an informer with favric8 flient before the operator is started that watches namespaces with the target label. On change it will call the registered controller ( the current API).

Basically we don't want to support such custom scenarios on purpose, since it's a minimal effort to implement it with the current API.

[btlem]

I agree that it can be implemented in that fashion. I think the idea was mainly to streamline the code, as the previous case of setting namespace can be done purely at the annotation level. Happy to resolve though, as there are workarounds possible

[csviri]

There are several approaches users configure this, one is to watch a config map, other would be what you described. We could think about some supporting classes, but would not add it directly into the core of the Operator. Feel free to create a PR for such.

[btlem]

Makes sense. I will proceed with the alternative and evaluate how it could be generalized / added in