[SURE-4037] Feature Request: "doNotDeploy" switch for targetCustomizations.

[NicolasGoeddel]

Is your feature request related to a problem?

I would like to define on fleet.yaml level if a Helm Chart gets deployed or not on a certain target. This could work the same way the spec.targets dictionary of a GitRepo works or with a dedicated switch like mentioned in the solution beneath.

Solution you'd like

This could look something like this:

targetCustomizations:
- name: dev
  clusterName: local
  clusterSelector:
    matchLabels:
      env: dev
  doNotDeploy: true

In this case the specified helm/kustomization will not be deployed on the targeted cluster with name local and label env=dev.

Alternatives you've considered

Alternatively it would be nice to also have a targets dictionary in fleet.yaml like we have it in GitRepo.

Anything else?

No response

[manno]

I see there is some need to:

• skip a bundle deployment on a cluster (doNotDeploy in fleet.yaml)
• override the cluster selection from fleet.yaml (overrideTargets in fleet.yaml)

This looks like a larger design discussion. For example, there might be installations where the dev team controls the git repo content, but only the admins can create GitRepo resources. They wouldn't want to give up control over cluster targeting. On the other hand, we do allow values customization already and clusters need to be in the same namespace as the git repo.

[gthieleb]

Is this feature already functional? Currently when using a targetCustomization to disable a specific cluster this leads to the behavior that bundles on other clusters are not visible on the UI.

targetCustomizations:
- name: ci
  doNotDeploy: true
  clusterSelector:
    matchLabels:
      env: ci
- name: all
  clusterSelector: {}

[kkaempf]

Should be fixed since Rancher 2.7.9

Please reopen if it still happens in a recent Rancher release (2.10.x)