Decouple static ResourceSet instances from ResourceSet

[matheuscscp]

This idea came from @cicci8ino, he has this use case in his home lab.

As a user I'd like to be able to create static instances of a ResourceSet template that are decoupled from the ResourceSet itself. This way I don't need to touch the ResourceSet anymore when I want to create more static instances, i.e. I don't touch the resource containing the template anymore. This is a reasonable choice from the perspective of using ResourceSets as templates, if I have a resource that encapsulates my template, I don't like the idea of having to specify the entire list of instances directly on the template resource itself.

Proposal

One way to do this would be adding a field matchLabels to resourceset.spec.inputsFrom and making resourceset.spec.inputsFrom.name not be required anymore, but rather requiring one of name or matchLabels. For example:

apiVersion: fluxcd.controlplane.io/v1
kind: ResourceSet
...
spec:
  ...
  inputsFrom:
  - kind: ResourceSetInputProvider
    matchLabels:
      tenant: my-tenant

On the ResourceSetInputProvider side, we could introduce a new value for spec.type, Static, and copy spec.defaultValues over to status.exportedInputs when this new type used. For example:

apiVersion: fluxcd.controlplane.io/v1
kind: ResourceSetInputProvider
...
spec:
  type: Static
  defaultValues:
    some: value
status:
  exportedInputs:
  - id: <object UID>
    some: value

Alternative

Another way to achieve this would be:

apiVersion: fluxcd.controlplane.io/v1
kind: ResourceSet
...
spec:
  ...
  inputsFrom:
  - kind: ConfigMap
    matchLabels:
      tenant: my-tenant

And then look for a key e.g. inputs.yaml in the ConfigMap and parse it from YAML. This alternative has a few disadvantages:

• Users have to write YAML in a multi-line string, while in the ResourceSetInputProvider alternative we can provide a way for users to write real YAML.
• We need to introduce support for a new kind ConfigMap in ResourceSet.
• Users may want to define which key to look at instead of inputs.yaml, so we would need something specific for ConfigMap in the inputsFrom structure.

[stefanprodan]

For the Static type we should export an id like for all other types, in this case it can be the object UID. We could also consider exporting name and namespace, as you would most probably need these values in the templates.

[matheuscscp]

Maybe inputName and inputNamespace to leave name and namespace free?