support cleanup targeting one specific release

[bitsofinfo]

support cleanup targeting one specific release, right now it appears its all or nothing?

[hickeyma]

@bitsofinfo There is capability like this which is currently available with the --delete-v2-releases flag of the convert command.

The idea of the cleanup command is to do a full cleanup of Helm v2. What is the use case where you only want to cleanup some of the releases?

[rimusz]

I think it makes sense to support cleanup for the specific release as well.
One of use cases you have many releases but want gradually one convert them to v3.
And of course you convert one, test it with helm v3, then do the clean up.

[bitsofinfo]

@hickeyma ok, i wasn't aware of that feature, it could sort of work, however my use-case is to

a) convert X of Y total releases, one by one verify
b) clean each release up one by one. (not all or nothing)
c) we have some releases that will still need to be v2 for a while, but others that I can target for v3 sooner.

I just think it would provide overall more flexibility for migrations, and having a targeted release argument on the cleanup command just is more intuitive as users (like myself) just naturally look there first for the option vs bundled w/ convert

[hickeyma]

@bitsofinfo I understand having this capability adds flexibility for the user. I am just a bit reluctant as the plugin was envisaged to be used to do an in-situ migration asap.

The reason I am interested in your use case is that I wanted to understand how you are using the plugin. In the Helm migration doc, there are 2 use cases shown:

• Strangler pattern: Helm 2 and Helm 3 co-exist on the same cluster. The user manages phasing out Helm v2 gradually and does not require v3 to manage any releases deployed by v2. All new releases are by Helm v3.
• In situ: Migrating Helm 2 to Helm 3 (ASAP). Convert to v3 releases and cleanup using the plugin.

Your use case is a hybrid of the two, in that you convert some releases but want to maintain some of the v2 releases as is. This should work but the onus will be on you to manage releases as Helm v2 could conflict with Helm v3 if try to deploy the same chart with same release name (conflict with k8s resources).

[bitsofinfo]

don't know, to me it seems pretty clear and a legitimate use-case. Yeah the onus is on the operator, however if I validate that the releases I successfully converted to v3, tested and accepted are good to go, there should be not need to force me to retain v2 references to them, because I can't cleanup them up in a targeted manner AFTER the convert command and my validation.

In all reality, all of our releases and supporting charts will covert over fine.

But let's say I have releaseA and releaseB.

1. I convert releaseA. I do NOT use the --delete-v2-releases flag as this leaves me in a non-ideal situation if there is something wrong w/ the converted release in v3 releases, I can't fall back to my v2 release reference.
2. This leaves releaseA and releaseB in v2 releases, and only releaseA is also in v3 releases
3. I validate that releaseA still functions fine as I upgrade the chart via helm3 etc and test
4. I target cleanup only releaseA, leaving only releaseB in v2 releases and releaseA exclusively in v3 releases.
5. I proceed to convert releaseB, it converts, but I notice there is an issue I discover after the fact (such as what I mentioned in Error migration : spec.clusterIP: Invalid value: "": field is immutable #125) that only occurs after the release is in v3 and goings through an upgrade later. In this case, I don't want to remove the v2 reference, but I am sort of forced to continue to use v2 to manage releaseB due to a bug in helm3.

I don't know, its not a big deal to me, I just see no harm in being able to target cleanup specific releases from the v2 releases db, vs only being able to do it as part of the convert process itself which leaves the operator no time to validate the conversion and only then after acceptance go and cleanup the targeted v2 release that was just converted. Not a fan of all or nothing.

thats said, its a great tool, thank you, so far working great!

[hickeyma]

don't know, to me it seems pretty clear and a legitimate use-case. Yeah the onus is on the operator, however if I validate that the releases I successfully converted to v3, tested and accepted are good to go, there should be not need to force me to retain v2 references to them, because I can't cleanup them up in a targeted manner AFTER the convert command and my validation.

I agree adding the capability is good and provides flexibility to the user. The issue is labeled as an enhancement to be added.

I am just a little wary about mixing 2 migration types/use-cases. Mixing both migrating and maintaining releases might lead to issues rather than strangling or migrating fully in-situ. As you say that is the responsibility of the operator.

[hickeyma]

@bitsofinfo Pushed PR #132 for this functionality. Can you give it a try and see how it works for you?

[bitsofinfo]

awesome! thanks. Handing off to @boarder981 to test this, they're working w/ me on this

[boarder981]

Is there a new version of the plugin that I can install with helm plugin install...? How do I test this otherwise?

[hickeyma]

@boarder981 You can clone the repo, get the PR fix and build that.

$ git clone git@github.com:helm/helm-2to3.git
Cloning into 'helm-2to3'...
remote: Enumerating objects: 84, done.
remote: Counting objects: 100% (84/84), done.
remote: Compressing objects: 100% (58/58), done.
remote: Total 445 (delta 38), reused 56 (delta 24), pack-reused 361
Receiving objects: 100% (445/445), 281.27 KiB | 2.93 MiB/s, done.
Resolving deltas: 100% (243/243), done.

$ cd helm-2to3/

$ git fetch origin pull/132/head:del-rel
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 5 (delta 0), reused 2 (delta 0), pack-reused 0
Unpacking objects: 100% (5/5), done.
From github.com:helm/helm-2to3
 * [new ref]         refs/pull/132/head -> del-rel

$ git checkout del-rel
Switched to branch 'del-rel'

$ make
export CGO_ENABLED=0 && \
go build -o bin/2to3 -ldflags "-X main.version=" ./main.go

$ ls -lrt bin
total 47480
-rwxr-xr-x 1 root root 48617017 Mar 11 09:04 2to3

[boarder981]

I did what you posted above and installed the plugin manually. This is what I see when I list plugins:

$ helm3 plugin list
NAME	VERSION	DESCRIPTION
2to3	0.5.0  	migrate and cleanup Helm v2 configuration and releases in-place to Helm v3

And just to confirm that I see the new -n option:

$ helm3 2to3 cleanup --help
cleanup Helm v2 configuration, release data and Tiller deployment

Usage:
  2to3 cleanup [flags]

Flags:
      --config-cleanup           if set, configuration cleanup performed
      --dry-run                  simulate a command
  -h, --help                     help for cleanup
      --kube-context string      name of the kubeconfig context to use
      --kubeconfig string        path to the kubeconfig file
  -l, --label string             label to select Tiller resources by (default "OWNER=TILLER")
  -n, --name string              the release name. When it is specified, the named release and its versions will be removed only. Should not be used with other cleanup operations
      --release-cleanup          if set, release data cleanup performed
  -s, --release-storage string   v2 release storage type/object. It can be 'secrets' or 'configmaps'. This is only used with the 'tiller-out-cluster' flag (default "secrets")
      --tiller-cleanup           if set, Tiller cleanup performed
  -t, --tiller-ns string         namespace of Tiller (default "kube-system")
      --tiller-out-cluster       when  Tiller is not running in the cluster e.g. Tillerless

Targeted release cleanup appears to work for me, but ONLY when using the long option name --name, and not -n. The following is some more detailed information as to what I did exactly. Please note that I have many releases installed with helm2, so the output below will be truncated for brevity. Also, I'm using the tiller plugin for helm2.

I see my release when I list with helm2

$ helm tiller run -- helm list -q
app-one-v1

I do not see it when listing with helm3, which is expected:

$ helm3 list -q -n omg-apps

Now I convert the release

$ helm3 2to3 convert --tiller-out-cluster --tiller-ns kube-system app-one-v1
2020/03/11 14:48:32 Release "app-one-v1" will be converted from Helm v2 to Helm v3.
2020/03/11 14:48:32 [Helm 3] Release "app-one-v1" will be created.
2020/03/11 14:48:32 [Helm 3] ReleaseVersion "app-one-v1.v1" will be created.
2020/03/11 14:48:32 [Helm 3] ReleaseVersion "app-one-v1.v1" created.
2020/03/11 14:48:32 [Helm 3] Release "app-one-v1" created.
2020/03/11 14:48:32 Release "app-one-v1" was converted successfully from Helm v2 to Helm v3.
2020/03/11 14:48:32 Note: The v2 release information still remains and should be removed to avoid conflicts with the migrated v3 release.
2020/03/11 14:48:32 v2 release information should only be removed using `helm 2to3` cleanup and when all releases have been migrated over.

Now I see it using both helm2 and helm3

$ helm tiller run -- helm list -q
app-one-v1

$ helm3 list -q -n omg-apps
app-one-v1

At first I was using the short option -n for cleanup and it didn't work. For example:

$ helm3 2to3 cleanup -n app-one-v1 --dry-run --tiller-out-cluster
2020/03/11 14:53:51 NOTE: This is in dry-run mode, the following actions will not be executed.
2020/03/11 14:53:51 Run without --dry-run to take the actions described below:
2020/03/11 14:53:51
WARNING: "Helm v2 Configuration" "Release Data" "Release Data" will be removed.
This will clean up all releases managed by Helm v2. It will not be possible to restore them if you haven't made a backup of the releases.
Helm v2 may not be usable afterwards.

[Cleanup/confirm] Are you sure you want to cleanup Helm v2 data? [y/N]: y
2020/03/11 14:53:56
Helm v2 data will be cleaned up.
2020/03/11 14:53:56 [Helm 2] Releases will be deleted.
2020/03/11 14:53:56 [Helm 2] ReleaseVersion "app-one-v1.v1" will be deleted.
2020/03/11 14:53:56 [Helm 2] ReleaseVersion "app-two-v1.v1" will be deleted.
2020/03/11 14:53:56 [Helm 2] ReleaseVersion "app-three-v1.v1" will be deleted.
...
...
2020/03/11 14:53:56 [Helm 2] Home folder "/Users/boarder981/.helm" will be deleted.

I then discovered that it DOES work when using the long option --name

$ helm3 2to3 cleanup --name app-one-v1 --dry-run --tiller-out-cluster
2020/03/11 16:17:44 NOTE: This is in dry-run mode, the following actions will not be executed.
2020/03/11 16:17:44 Run without --dry-run to take the actions described below:
2020/03/11 16:17:44
WARNING: "Release Data" will be removed.

[Cleanup/confirm] Are you sure you want to cleanup Helm v2 data? [y/N]: y
2020/03/11 16:17:47
Helm v2 data will be cleaned up.
2020/03/11 16:17:47 [Helm 2] Release 'app-one-v1' will be deleted.
2020/03/11 16:17:47 [Helm 2] ReleaseVersion "app-one-v1.v1" will be deleted.

Hopefully this was helpful. Let me know if you need to know anything else.

Thanks!

[boarder981]

I forgot to mention that when I did the cleanup for real (the one I posted above was dry run), it did purge the release data from helm2. I still see it in helm3.

Also one other suggestion. When you perform a dry run, this warning appears:

WARNING: "Release Data" will be removed.

Can you make it print the release name please? That way there is more certainty of what exactly will be deleted before you type y :)

[hickeyma]

@boarder981 Thanks for testing and the great feedback. @marckhouzam got in first about -n short key (#132 (comment)). Will probably just remove it and stay with --name flag.

Good suggestion about the warning message. Will take on board.

[hickeyma]

PR #132 merged.