Got Error: RELEASE_NAME has no deployed releases about helm-2to3 HOT 14 CLOSED

Thanks! I created #112

from helm-2to3.

what helm tiller run -- helm list shows you?
do you use default namespace kube-system to store tiller releases?

from helm-2to3.

I store releases in their respective namespace. E.g., the above release is stored in a namespace called monitoring.

So helm tiller run monitoring -- helm list gave me the correct result:

from helm-2to3.

Btw, I ran export HELM_HOST=localhost:44134 && helm tiller start-ci NAMESPACE when I need to use Helm so I ran the command and then used the plugin

from helm-2to3.

then you need to use one more flag --tiller-ns and provide the namespace name for each release.
As by default plugin uses kube-system namespace to check for releases

from helm-2to3.

Thank you. It certainly fixed the issue. Sorry again for not reading the help message properly

from helm-2to3.

no worries, glad it is working for you

from helm-2to3.

I am seeing the same error, tiller is in the kube-system namespace using secrets to hold v2 configuration.

$ helm3 2to3 convert microservice --dry-run
2020/01/23 12:06:07 NOTE: This is in dry-run mode, the following actions will not be executed.
2020/01/23 12:06:07 Run without --dry-run to take the actions described below:
2020/01/23 12:06:07
2020/01/23 12:06:07 Release "microservice" will be converted from Helm v2 to Helm v3.
2020/01/23 12:06:19 [Helm 3] Release "microservice" will be created.
Error: microservice has no deployed releases
Error: plugin "2to3" exited with error

Any ideas?

from helm-2to3.

@hickert33 This has same symptoms but is a different issue. Do you mind raising a new issue to better track this?

from helm-2to3.

@hickert33 you are missing flag --release-storage secrets

it should be:

$ helm3 2to3 convert microservice --release-storage secrets --dry-run 

as by default plugin checks releases in the configmaps

from helm-2to3.

@rimusz The --release-storage flag is only used when the plugin is connecting to an out of cluster Tiller. Otherwise, it picks up the storage backend from Tiller in the cluster.

I think it is worth opening the new issue to at least track @hickert33 issue.

from helm-2to3.

then yes we need a new issue

from helm-2to3.

Hello guys, I've altered an existing GO library to migrate secrets to configmap so this problem with migration doesn't happen anymore.

here

from helm-2to3.

Hello guys, I've altered an existing GO library to migrate secrets to configmap so this problem with migration doesn't happen anymore.

@suciuandrei94 This is not related to issue, thanks.

from helm-2to3.