Support for `helm template` and/or `helm install/upgrade --dry-run`

[SleepyBrett]

SUMMARY

There are broadly two ways to use Helm. You can use it how the module supports, with full 'package management' features ('helm install, helm upgrade'). Another way is to use it to generate raw manifests ('helm template'). I'm not seeing support for the later, I may be missing something, and if so maybe this is a 'make the documentation clearer' ticket.

ISSUE TYPE

• Feature Idea

COMPONENT NAME

Seems like you could just add a, and I'm spitballing here, method or just_template property that could be set (default to 'install/upgrade') to make ansible simply generate the manifests.

ADDITIONAL INFORMATION

I'm actually in a position where I need to replace non helm managed objects with helm managed objects. This requires me to find the objects that exist on cluster that would be replaced by helm and patch them with various labels and annotations before attempting a second helm upgrade -i.

The process being:

Try helm install, capture error. If error is expected 'this stuff isn't managed by helm' then:

1. run helm template in the same way we tried to run helm install.
2. extract all the object names and types
3. loop through objects and patch existing objects
4. rerun helm install

EDIT:

I just determined that you can use helm upgrade/install with the --dry-run flag to get the manifests to output as well. This would probably be easier to implement.

Turns out for my usage --dry-run won't do what I want, when helm sees an object it hasn't deployed it fatals even under dry run and won't output the manifests. So support for template is what I need.

[tima]

Have you tried using check_mode on the helm task? It should have the same effect as a helm --dry-run.

[SleepyBrett]

Thanks for the reply @tima

https://github.com/ansible-collections/community.kubernetes/blob/main/plugins/modules/helm.py#L539

I'm not super python literate, however... It looks like checkmode does not run a dry-run at all. (a simple grep on the source code contains no reference to dry-run)

Instead it seems to compare the values provided with the values already present in the release on the cluster and little else, I'm not exactly yet following the logic here but I assume it also compares chart version somewhere as well.

[Akasurde]

@SleepyBrett Do you think we can add a parameter to specify --dry-run in helm command?

# helm install wordpress bitnami/wordpress --dry-run --namespace=default --output yaml

but not sure if we can use the same stdout YAML in helm command. Comments?

[goneri]

@SleepyBrett Do you think we can add a parameter to specify --dry-run in helm command?

# helm install wordpress bitnami/wordpress --dry-run --namespace=default --output yaml

but not sure if we can use the same stdout YAML in helm command. Comments?

Can we use the check mode for that? https://docs.ansible.com/ansible/latest/user_guide/playbooks_checkmode.html#using-check-mode

[gravesm]

I want to clarify what the feature here is. Are we just adding support for helm template to output a local rendering of the chart? Or are we supporting the option for helm to adopt existing resources in the chart that it doesn't own?

[Akasurde]

I think we need a separate module (like helm_template) to satisfy this requirement. Since we are just dealing with templates here.

[tima]

I'm getting lost in the what and the why here also.

What I am getting sounds rather programmatic -- you're going to need conditional logic, parsing and data manipulation on top of a helm_template. Sounds like that ask is for support of a specific adoption scheme of existing resources (migration?) and what's needed here is not a helm_template module but a helm_sleepybrett_migration module.

[tima]

I've created a separate issue for the helm_template in #367. I'm going to recategorize and keep this issue around for now because I think it includes things beyond just that module.

[Akasurde]

helm_template can be used to create a template. Hence, closing this issue. Feel free to open a new issue if required.