Dry Run option

[Uva-Vj]

User Story

As a user I would like the option of dry run before installing helm charts through CAAPH to understand what exact changes will be made before the helmchartproxy is applied and k8s resources are created/updated.

Detailed Description

The dry run option should probably run helm template and kubectl diff the changes between the generated manifests and the actual resources running in all selected clusters and provide the diff output either in helmreleaseproxy or in a new CRD. This would help to get an idea of what exact changes will be made in which resources and clusters.

Anything else you would like to add:

I could add this as a step in a CI pipeline but the CI pipeline would have to interact with all workload clusters to run helm/kubectl commands against them to get the output which doesn't seem like an ideal scenario while using CAAPH to apply them through the management cluster.

/kind feature

[Jont828]

@Uva-Vj I think we could add this feature if there's a sensible way to show the install changes/diff. I believe when you do --dry-run or helm template it will spit out a ton of YAML text, which isn't really feasible to show in the status or spec for the HelmReleaseProxy. I think a dry-run for the cluster selection would be pretty easy to add, and possibly to see if the chart would produce an error. Let me think on this one.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale