helm 2 to helm 3 upgrade story

[michelleN]

it'd be nice if it was seamless. migration path.

• possibly a plugin
• baked into helm 3? mmm no
• at the very least, some steps

Things we need to do:

• Release storage is now config maps. These are going to be CRDs... transition story would be nice.
• backup and mirror step would be nice. hand holding required. need to feel safe.

Sincerely,
Helm 3 Deep Dive from KubeCon Seattle 2018

Assigned to: Josh Dolitsky. He volunteered.

[henrynash]

We should also make sure we give guidance on changes in operational workflow that the 2->3 impact might cause. E.g., operational tooling might want to still be able to "list all releases" - which in v2 is easy, but when all the RELEASE object are in their own namespaces, it is not obvious how that might work

[rimusz]

proposed functionality:

1. list - list v2 releases
2. upgrade v2_release_name --dry-run (dry run of upgrade from v2 to v3)
3. upgrade v2_release_name (run upgrade from v2 to v3)
4. remove v2_release_name

[prydonius]

but when all the RELEASE object are in their own namespaces

I guess this could just be a kubectl get helmrelease --all-namespaces, but it should definitely be documented, or helm list could become an alias for that?

Release storage is now config maps. These are going to be CRDs... transition story would be nice.

Does a standalone migration tool that folks can run to migrate from Helm 2 -> 3 make sense? It could automate backing up ConfigMaps and converting them to HelmRelease objects?

[jdolitsky]

I do indeed volunteer :) Who wants to work on defining this with me?

Does a standalone migration tool that folks can run to migrate from Helm 2 -> 3 make sense? It could automate backing up ConfigMaps and converting them to HelmRelease objects?

Yes. My suggestion would be for us to add a simple, Helm-org supported plugin to help with the transition.

We can name it helm 2to3 after the 2to3 Python module, which is actually a similar project that helps in the one-time conversion of Python 2 to Python 3 source code.

The plugin may, for example, have subcommands such as convert and tips:

$ helm 2to3 convert myrelease --dry-run

NOTE: This is in dry-run mode, the following actions will not be executed.
Run without --dry-run to take the actions described below:

[Helm 3] Release "myrelease" will be created.
[Helm 3] ReleaseVersion "myrelease.v1" will be created.
[Helm 3] ReleaseVersion "myrelease.v2" will be created.
[Helm 3] ReleaseVersion "myrelease.v3" will be created.
[Helm 2] ConfigMap "myrelease.v1" will be deleted.
[Helm 2] ConfigMap "myrelease.v2" will be deleted.
[Helm 2] ConfigMap "myrelease.v3" will be deleted.

$ helm 2to3 tips

The following is a summary of quick overview of the differences in using the Helm CLI
when migrating from Helm 2 to Helm 3. For more info, please see https://helm.sh/2to3

  > Listing releases across all namespaces
      [Helm 2] helm list
      [Helm 3] kubectl get helmrelease --all-namespaces

  > Downloading a specific chart version
      [Helm 2] helm fetch myrepo/mychart --version 2.0.1
      [Helm 3] helm pull myrepo/mychart:2.0.1

...

We can add additional subcommands to aid in other areas as they come up.

The idea would be that people could sort of use this tool as a one-and-done for the migration then uninstall it when their systems are completed moved over to Helm 3.

[rimusz]

we also have to support helm v2 releases stored in secrets

[bacongobbler]

Yes. My suggestion would be for us to add a simple, Helm-org supported plugin to help with the transition.

+1 for making this a supported plugin outside of core but within the Helm org. The handling logic for converting releases from v2 to v3 will likely be a one-and-done sorta deal, so it'd make sense to keep the code as a separate project.

Also +1 for helm 2to3.

[henrynash]

+1 for a separate tool, seems fine.

I would suggest we need to support two modes of upgrading:

1. Those that want to convert-in-place - which is what this thread has been discussing so far
2. Those that won't trust any kind of conversion tool (someone did raise this at the deep dive in Seattle) - and would rather run v2 and v3 helm alongside each other and effectively drain away v2 as they release new versions of their applications. I don't think we need any extra tooling to support this - rather we need to document the recommended way of doing this, limitations and any pitfalls to avoid.

...and yes I do volunteer to help :-)

[prydonius]

Those that won't trust any kind of conversion tool (someone did raise this at the deep dive in Seattle)

Interesting, I wonder if helm 2to3 could have a dry-run mode that just output the HelmRelease CRDs it was going to create to help along that usecase.

[rimusz]

yes helm 2to3 should support the dry-run mode

[hickeyma]

helm-2to3 plugin available in Helm Org. Like Helm 3 that is in Beta, it is good to try out but not in production yet.

[hickeyma]

I think that the upgrade story can be closed. Here are some of the key points:

• Helm 2 charts install/template/--dry-run supported as is
• List releases by --all-namespaces
• Helm 2 and Helm 3 can work concurrently in the same cluster
• Migration document published, for migrate in-place and manage both version information
• Helm 2to3 plugin in Helm Org, tool for migrate in-place

Migration feature helm/helm#5892 is now complete.

[bacongobbler]

closing as per @hickeyma's comment above.

[hiro5id]

The https://v3.helm.sh/docs/intro/v2_v3_migration link is broken

[hickeyma]

@hiro5id Thanks for mentioning. It was moved to: https://helm.sh/docs/topics/v2_v3_migration/