Allow Wildcard or All Namespace for Copy Collector

[ndrafahl]

Describe the rationale for the suggested feature.

Currently the copy collector works by specifying only a single, hard-coded, known namespace, to copy files off of pods found by a given selector.

As part of our application, we have a feature that allows a user to deploy a namespace and deployments into the namespace (the application interacts directly with helm to deploy), and the user can define what that namespace can be (in a way, they define a portion of the namespace, where we give it a predefined suffix; i.e. kinetic-tenant-<SLUG_DEFINED_BY_USER>.

We'd like to be able to copy files off of pods we know that exist as part of these "deployments" and add them into the support bundle we collect from the user when something is going wrong with the platform.

If we could tell the copy collector to target the namespace of kinetic-tenant-* with the selector (or just * or "all namespaces"), we could "dynamically" grab all of the files from all pods, regardless of what the user may have specified as their "slug".

Describe the feature

This allows for collecting files off of running pods when we may not know what namespaces are currently deployed (via the support bundle definitions).

Describe alternatives you've considered

We could likely write our own custom collector / image that goes and finds all namespaces that match kinetic-tenant-* and manually run the kubectl cp... commands from within that pod to zip up the files and put them into the support bundle.

Additional context

See https://community.replicated.com/t/run-copy-collector-against-wildcard-namespaces/1213.

[bagel-dawg]

Our product is beginning to act as a kubernetes operator and will create namespaces with randomized names that we would like to be able to include in a support bundle. These namespaces are labeled appropriately, so a label selector for the namespaces label would work great for our purposes.

This feature would go along with that so that we don't need a separate process for gathering logs in arbitrary namespaces (or by label selector).

[chris-sanders]

Given we've now implemented the ability to put the spec into a helm chart so you can template the spec with the namespace the same as the rest of the chart. Does that enable you to use 'dynamic' namespaces like you describe, or where/how does that fall apart in your use case?

Let me clarify some there are actually two use cases here. If you're using an operator the Helm portion isn't relevant.

However, for an operator you can install specs in the cluster in the given namespace and apply labels. Troubleshoot can then select specs by label allowing you to select the spec that matches the label you want, and that spec knows the namespaces it's collecting from.

[crdant]

connecting dots from my discussion with @ndrafahl today and @chris-sanders last comment, Helm templating felt insufficient since KOTS wouldn't be able to determine the namespaces. I recommended that each Helm chart contain it's own support bundle definition (and preflight definition) which would keep like concerns together and allow for {{ .Release.Namespace }} as the namespace.

[chris-sanders]

Yes, that's what I'm trying to say but not as clearly as you :)
If that's not working for any reason p lease let us know!