Support for namespace label selectors

[mpreu]

Hi,

at the moment, the ClusterLogForwarder API can only handle log selection by static namespaces or pod labels. It would be nice if label selectors can be supported for namespaces as well. This would enable much easier log selection when multiple namespaces do not share a common glob expression.

[jcantrill]

Does kubernetes support listing pods by namespace labels? I've never tried. If not then it makes it much more difficult to support this request.

Also, are you expressing this limitation with the latest release which includes the ability to provide namespace and container globs?

[mpreu]

Hi,

I do not think it is supported. But is listing pods by namespace label really necessary as it would just avoid one additional filtering step?

I assume from the question, the current code just lets vector find the correct targets without much pre-processing?

I am aware of the latest version and the globbing feature. While this is useful for some situations, label selection is more flexible and seems in-line with the already implemented API.

In my use case, I have a lot of namespaces I would want to select for log-forwarding, regardless of the applications in them. As they do not have a common naming scheme, globbing is not really helping me here. But I have easier access to the namespace labels (and their modification to fit the use-case).

[jcantrill]

I assume from the question, the current code just lets vector find the correct targets without much pre-processing?

Currently vector essentially is capable of doing the equivalent of oc get -l which becomes the list of pods from which it reads logs. We couple this with a file glob to further filter out by namespace based on what is spec'd; those files simply are not read. This is the most efficient.

Looking at the available config, it may be possible to accomplish this using this setting. This will require investigation.

Consider trying it yourself by:

• setting the ClusterLogging.spec.managementState to "Unmanaged'
• Extracting the config secret
• Adding the field to the toml
• Updating the secret
• restarting the pods with 'oc delete -lcomponent=collector'

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale