There should be a way to filter out resources from the final output

[sudohikumar]

The way cue handles exports using -e flag to just give output of specific element, cuestomize should also provide a way to filter out resources from the final output.

Use case

Suppose we have 1 resource that needs to be created beforehand as part of bootstrap. Then we can apply other resources on the cluster.
outputs dumps all the resources in 1 single file by default.
Currently, the way to do using cuestomize are the following

• yq split and search and write our own custom logic for that filtering
• slice all the resources in a folder and again write logic to filter out specific resources
• Have multiple modules exported separately based on the usecase. (I think this adds additional files but cleaner than above 2).

Suppose we have main.cue as follows

...
outputs: {
	cm: #ConfigMap
	deployment: #Deployment 
         ....
}
...

I can simply do this via vanilla cue cli

cue export -e outputs.cm --out yaml
cue export -e outputs.deployment--out yaml

Similar thing is not possible currently here.

Proposals

I propose 2 types of solutions. Both has pros and cons. But it makes filtering easier.

1. Output multiple outputs as keys than can be used to filter out on client side.
   Example:

outputs: {
	controllerResources: {
		cm: #ConfigMap
		deployment: #Deployment 
	}
	baseResources: {
		sa: #SA
		role: #Role
	}
}

This can be further refined if accepted.
2. Similar to includes feature, we also have filter spec than can filter out fields to give final output.
Example:

apiVersion: cuestomize.dev/v1alpha1
kind: Cuestomization
...
filter:
  - group: apps
    version: v1
    kind: Deployment
    name: manager
    namespace: default

This will only give deployment spec with that filter match. This will be client side filtering.

[lorenzofelletti]

Hi @sudohikumar, thank you for opening this issue.

I can see the pain in trying to have conditional rendering of some resources.

I like the idea of allowing from kustomize side to control which output field you want to extract from the module as you're suggesting in your first proposal.

That would fit in well within CUE, and will mimic a feature the CLI already offers.

note: differently from the CLI, I think leaving the default extracted field to be outputs would help people to get started with, without having to worry of understanding how to plumb kustomize and CUE together.

Your second proposal is probably the easiest to implement, and filter-like mechanisms fits in well with kustomize. However, I don't think it really fits into the philosophy of CUE-Lang:

• say one writes a wrong filter and some resources are wrongly filtered out
• they would get an invalid output generated by a valid CUE module (because from the CUE POV a correct set of input was provided, and all the corrected resources were generated)
• so the kustomize build would succeed, but then the deployment fails because of some missing resources, confusing the user.

So, I think in order not to weaken the benefits of CUE validations, but still allow a flexible and user-friendly approach, your first proposal should be the way forward in this case.

I'll leave below a workaround strategy that can be used until we have such a feature implemented

Workarounds

CUE-Lang provides the if functionality that can one can leverage, e.g.

outputs: {
	if input.render == "controller": {
		controllerResources: {
			cm: #ConfigMap
			deployment: #Deployment 
		}
	}
	if input.render == "base": {
		baseResources: {
			sa: #SA
			role: #Role
		}
	}
}

However, this model quickly becomes unmanageable once you get past 2/3 if statements.

[lorenzofelletti]

outputs: {
	controllerResources: {
		cm: #ConfigMap
		deployment: #Deployment 
	}
	baseResources: {
		sa: #SA
		role: #Role
	}
}

apiVersion: cuestomize.dev/v1alpha1
kind: Cuestomization
metadata:
  cuestomize.output.selector: "baseResources,baseResources"