app-name has no deployed releases

Output of helm version:
$ helm version
Client: &version.Version{SemVer:"v2.13.1", GitCommit:"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.13.1", GitCommit:"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"}

Output of kubectl version:
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.0", GitCommit:"641856db18352033a0d96dbc99153fa3b27298e5", GitTreeState:"clean", BuildDate:"2019-03-25T15:53:57Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.11", GitCommit:"637c7e288581ee40ab4ca210618a89a555b6e7e9", GitTreeState:"clean", BuildDate:"2018-11-26T14:25:46Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.):  Amazon
What is happening:
After few broken deployments, helm (or tiller) is broken and all subsequent deployments (no matter if fixed or still broken) ends with following error: app-name has no deployed releases
How to reproduce:
We have
spec:
  revisionHistoryLimit: 1

but i think it is not relevant.
Path a:

Deploy any service - working
Break it, e.g. by exiting containers after startup, so the whole deployment will be broken
Repeat it exactly 3 times
All next deployments will have error, no matter if fixed or broken

Path b:

Deploy broken service - see #2 above
All next deployments will have error, no matter if fixed or broken

Hi - can you give some more detail on how you're deploying? are you using helm upgrade --install by any chance? And if you do, what is the state of the deployment when it's broken (helm ls) - presumably it is Failed?
If this is the case, a helm delete --purge <deployment> should do the trick.

hi, sorry for missing info.
Yes i am using helm upgrade --install
And yes, the deployment stays in Failed forever.
Unfortunately the helm delete --purge <deployment> is not an option here at all. I cannot just delete production services because of that :)
The question is why helm cannot recover after 3 consecutive failures.

the only way to sort that without deleting the release add --force

--force to what? to helm upgrade --install ?
and if yes, then it means that above issue is actually expected feature and we should use --force with every deployment?

yes, of course to helm upgrade --install :)
and yes you should use --force with every deployment

does it means that --force will deploy broken releases forcibly as well?
--force                    force resource update through delete/recreate if needed
what is the delete condition?
i really dont want to end up with deleted production services.
and do you really think that it is not an issue?

See https://github.com/helm/helm/issues/3208

Cannot agree more. Our production is experiencing the same error. So deleting the chart is not an option, and forcing the install seems dangerous. This error is still present with Helm 3. So might be good to include a fix or safer workaround.

it can be fixed by removing "status": "deployed", in storage.go:136
See: https://github.com/helm/helm/pull/6933/commits/638229c3d3646e78d0fd5157309f8aeadfd01af1
I will fix the Pull Request when i have time.

The code in place was originally correct. Removing status: deployed from the query results in a false positive, allowing Helm to upgrade from the last release regardless of the state it was previously in, which could lead to unintended results.
If you can provide the output of helm history when you hit this bug, that would be helpful. It's more helpful to determine how one ends in a state where there are no releases in a deployable state.

I'm encountering this issue when deploying for the first time to a new cluster. Should I use --force too?

I encountered this issue when I deleted the previous release without using --purge option.
helm delete --purte <release-name>

I am also encountering this issue.

@bacongobbler
I hit this with helm3. History is completely empty when this happens, although broken k8s resources are there since attempt 1.
Reproduction seems really easy:

helm upgrade --install
correct what caused the container to exit, e.g. value with invalid arg for the executable inside container, and try again
-> Error: UPGRADE FAILED: "foo" has no deployed releases

Seems the --atomic flag may be a way forward in my (CI/CD) scenario. Since it cleans out initial failing release completely as if it never happened, I don't hit this issue on next attempt.

Same here, I don't see how using delete or --force can be advised especially when there are persistent volumes in place, I've already lost all grafana dashboards because of this once, not doing it again :)

@alex88 can you provide the output from helm history? I need to know how others are hitting this case so we can try to nail down the root cause and find a solution.

@bacongobbler sure I would really love to see this fixed as I'm really cautious of using helm because of having lost persistent volumes a couple times (probably my fault tho)
REVISION	UPDATED                 	STATUS	CHART        	APP VERSION	DESCRIPTION
4       	Wed Dec  4 02:45:59 2019	failed	grafana-4.1.0	6.5.0      	Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
5       	Mon Dec  9 12:27:22 2019	failed	grafana-4.1.0	6.5.0      	Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
6       	Mon Dec  9 12:33:54 2019	failed	grafana-4.1.0	6.5.0      	Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
7       	Mon Dec  9 12:36:02 2019	failed	grafana-4.1.0	6.5.0      	Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
8       	Mon Dec  9 13:06:55 2019	failed	grafana-4.1.0	6.5.0      	Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
9       	Mon Dec  9 13:38:19 2019	failed	grafana-4.1.0	6.5.0      	Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
10      	Mon Dec  9 13:38:51 2019	failed	grafana-4.1.0	6.5.0      	Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
11      	Mon Dec  9 13:41:30 2019	failed	grafana-4.1.0	6.5.0      	Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
12      	Mon Dec  9 13:56:01 2019	failed	grafana-4.1.0	6.5.0      	Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
13      	Mon Dec  9 15:15:05 2019	failed	grafana-4.1.0	6.5.0      	Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims

basically I've tried multiple times to run the upgrade to change some env variables and since while there was the deploy error the env variables changed anyway I kept doing so ignoring the error

how did you get into a state where every release has failed?

how did you get into a state where every release has failed? Where's release 1, 2, and 3?

changing env variables (had to do multiple changes) and running an upgrade every time, it was changing the env variables but I had no idea on how to fix the persistent volume error

Helm3: I am having the similar issue while upgrading istio, the release failed, now I can not redeploy it even though a small error in templates is fixed. I cant delete production release since it will also delete associated ELB with istio-ingress service.

Is there any future work to change the logic when the initial release ends up in a failed state ?

What do I have to do if downtime is not accepted?
% helm upgrade prometheus-thanos --namespace metrics -f values.yaml .
Error: UPGRADE FAILED: "prometheus-thanos" has no deployed releases
% helm install --atomic prometheus-thanos --namespace metrics -f values.yaml .
Error: cannot re-use a name that is still in use
% helm version
version.BuildInfo{Version:"v3.0.1", GitCommit:"7c22ef9ce89e0ebeb7125ba2ebf7d421f3e82ffa", GitTreeState:"clean", GoVersion:"go1.13.4"}

What do I have to do if downtime is not accepted?

for now I just use helm to generate the templates and I manually save them locally and apply

Seems the --atomic flag may be a way forward in my (CI/CD) scenario. Since it cleans out initial failing release completely as if it never happened, I don't hit this issue on next attempt.

@henrikb123 the above works only if you allways used --atomic flag. Otherwise it will not work. For example: try to install a broken chart without it and them run the same command with the --atomic flag. It will break. FYI I'm using the latest Helm version -> 3.0.2

@alex88 can you provide the output from helm history? I need to know how others are hitting this case so we can try to nail down the root cause and find a solution.

@bacongobbler why don't you just do what @henrikb123 said here to simulate the problem? As pointed out by @henrikb123, the history is completely empty. I can confirm that as well. Take a look please:
$ helm upgrade --install --cleanup-on-fail --reset-values --force --namespace teleport --values values.test.yaml teleport ./
Release "teleport" does not exist. Installing it now.
Error: Secret "teleport-secrets" is invalid: metadata.labels: Invalid value: "helm.sh/chart:teleport-1.0.0app.kubernetes.io/managed-by": a qualified name must consist of alphanumeric characters, '-', '_' or '.', and must start and end with an alphanumeric character (e.g. 'MyName',  or 'my.name',  or '123-abc', regex used for validation is '([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9]') with an optional DNS subdomain prefix and '/' (e.g. 'example.com/MyName')

$ helm history teleport
Error: release: not found

$ helm upgrade --install --cleanup-on-fail --reset-values --force --namespace teleport --values values.test.yaml teleport ./
Error: UPGRADE FAILED: "teleport" has no deployed releases

I also ran into this with Istio.
There's an Istio issue with 1.4.3 where one of the jobs the install runs will fail if it can't get to the Kubernetes API server. It then leaves a job behind and if you try to re-run the Helm command it fails because the job exists already. I tried deleting the job, tweaking things, and re-running the upgrade but was never successful... and now I'm stuck.
(That's how you can get into an all-failed release state, since there was a question about that.)
REVISION	UPDATED                 	STATUS	CHART      	APP VERSION	DESCRIPTION
10      	Tue Jan 14 09:17:00 2020	failed	istio-1.4.3	1.4.3      	Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition
11      	Tue Jan 14 09:22:21 2020	failed	istio-1.4.3	1.4.3      	Upgrade "istio" failed: post-upgrade hooks failed: warning: Hook post-upgrade istio/charts/security/templates/create-custom-resources-job.yaml failed: jobs.batch "istio-security-post-install-1.4.3" already exists
12      	Tue Jan 14 09:23:10 2020	failed	istio-1.4.3	1.4.3      	Upgrade "istio" failed: post-upgrade hooks failed: warning: Hook post-upgrade istio/charts/security/templates/create-custom-resources-job.yaml failed: jobs.batch "istio-security-post-install-1.4.3" already exists
13      	Tue Jan 14 09:25:58 2020	failed	istio-1.4.3	1.4.3      	Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition
14      	Tue Jan 14 09:35:21 2020	failed	istio-1.4.3	1.4.3      	Upgrade "istio" failed: post-upgrade hooks failed: warning: Hook post-upgrade istio/charts/security/templates/create-custom-resources-job.yaml failed: jobs.batch "istio-security-post-install-1.4.3" already exists
15      	Tue Jan 14 09:38:08 2020	failed	istio-1.4.3	1.4.3      	Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition
16      	Tue Jan 14 14:02:47 2020	failed	istio-1.4.3	1.4.3      	Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition
17      	Tue Jan 14 14:19:44 2020	failed	istio-1.4.3	1.4.3      	Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition
18      	Tue Jan 14 14:33:36 2020	failed	istio-1.4.3	1.4.3      	Upgrade "istio" failed: post-upgrade hooks failed: warning: Hook post-upgrade istio/charts/security/templates/create-custom-resources-job.yaml failed: jobs.batch "istio-security-post-install-1.4.3" already exists
19      	Tue Jan 14 14:36:59 2020	failed	istio-1.4.3	1.4.3      	Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition

This is with Helm 3.0.2.

This wasn't an issue for me on older versions of helm, and there are no failed deployments, kubectl is showing running services and everything is working.
Now I am simply trying to run helm upgrade -f app.yaml --namespace prometheus prometheus prometheus and I just get the error: Error: UPGRADE FAILED: "prometheus" has no deployed releases but I cannot try any of the work arounds because this is in prod...

@zrsm what we're doing for now is generating the yaml files using helm and using kubectl diff/dry-run to preview changes before applying them manually

@zrsm what we're doing for now is generating the yaml files using helm and using kubectl diff/dry-run to preview changes before applying them manually

Thanks for the reply, I downgraded to 2.15.1 but ran into similar issues, however, I tried something like deleting my ~/.helm and then I reinitialized the tiller serviceaccount from kubectl, after doing this I was able to apply charts to kubernetes. I will try testing this with helm 3 later on today and reply back with a fix. I have a feeling this might have been the issue.

Hi there, so I tested this out... and looks like performing the following command after also deleting my previous ~/.helm/ solved this...
helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | kubectl apply -f -
I am thinking if you install a new helm edition and your serviceaccount stuff isn't situated  (I wiped my laptop and restored at some point) then this happens and this was the fix. I hope it works for you also.

This bug is ongoing in Helm 3, is there a planned fix?

Also running into this issue with a fresh cluster and a fresh deployment due to a timeout. Apparently we now need to manually connect to our kubernetes cluser to fix everything that helm broke.
Can we make sure this issue gets resolved asap?

I agree. This is driving me nuts. I'm going to work on fixing it.  Wish me luck.

I agree. This is driving me nuts. I'm going to work on fixing it. Wish me luck.
thanks and good luck!

I wouldn't mind getting a few of you to look at PR #7653 .
I believe this will solve the issues described above.

Can't believe it's still open with no reaction from maintainers

cc @bacongobbler  @mattfarina

Would using helm delete --purge (v2) or helm uninstall (v3) also work, as they are all failed releases?

@hickeyma not always; this could also be the result of helm release metadata corruption so in some cases uninstalling could delete resources under load.

sometimes the release is not failed but timeout and helm labels it as the failing one, and next time it shows as has no deployed release, but the app is actually fully functional, it happened to me many times, so I had to change the release label to deployed one. it it not always an option to do helm delete --purge (v2) or helm uninstall (v3)

@rimusz how are you changing the release label?

@dudicoco by manually editing the helm v3 latest release secret, you could automate that and use kubectl patch

have moved over to https://github.com/k14s/kapp which works like a charm.

@rimusz that's what I thought, thanks.

I also back-ported my fix to helm 2 in #7668 but am still awaiting feedback on #7653

Same issue here,
A release deployed with --wait did timeout, and finally is up and running. It is still marked as failed.
And so, later deployments are failing too.
This means the release status is not a reliable information.

We use k8s in our company for many services in production.
For a few times in a month, we have same problems with helm on different applications ("*** has no deployed releases.").
We used different versions of helm (from 2.7 till 3.0.3).
The problem is not fixed.
This causes a lot of discomfort for our users (developers that deploy applications in cluster)
Each time, when we hit it, we just patch the latest release secret (status to deployed).
Is there any plan to add a behavior that ignores last releases state and install new releases?

Having --history-max set to 10 (default value), first release succeeded.
Then, next 10 releases failed on:
Error: UPGRADE FAILED: timed out waiting for the condition (It was simulated, thus expected).
After that, next (11th failed) release failed on:
Error: UPGRADE FAILED: "app" has no deployed releases (that's the problem!)
Would it be possible that helm always preserves the latest successful release in the history, in addition to the 10 most recent ones (whatever their status is)?

I love the idea. Would need to modify the storage functionality but I think it could be done.

https://github.com/helm/helm/pull/4978 was merged for Helm 2. Perhaps it wasn't ported over to Helm 3. If someone has the time and wants to port it over, please feel free.

I tried my hand at porting this to Helm 3 with #7806, and would love to see it merged ASAP. Thanks, @ultimateboy!

What about releases that fail on first install, i.e. have no past successful releases?
We are using upgrade --install for idempotent deployment of helm releases and when the first release  fails, all the subsequent invokes of upgrade --install fail with "has no deployed releases" error (this issue).

The "first release failing" scenario is at least more manageable, because you usually run it manually (and can apply a fix right then and there)—as opposed to having helm run by a CI/CD system that just starts failing one day and doesn't recover even after fixing the code.
It should still be fixed of course.
There is also value in preserving the last successful release anyway, not just because of this bug. E.g. debugging issues with values file, etc.

@peterholak The "first release failing" scenario is sometimes also done with a CI/CD and for example - we have restricted access to our cluster and can't even make a "helm ls" how are we supposed to "manage this"?

This issue should be a high priority one seeing that most people use helm in production. I could run the helm install with --atomic, but what if I'd like to inspect the reason for failure before deploying? I can inspect and then upgrade because it's stuck.

We are also using upgrade --install for idempotent deployment of helm releases. Because that is how automated ci/cd piplines work. We do not plan to manually fiddle around with helm because that would bypass our deployment pipeline.
In an automated deployment pipeline the first deployment will almost always fail. Subsequent deployments must not be triggered differently than the first attempt.
Please consider raising the priority of this issue considerably.

The experience is soooooooo bad, we can't simply delete the whole release, because it's in production!  It will cause the server downtime! How can we deal with this issue in the end?

Also, can somebody please remove the question/support label? This issue is not about missing documentation, but about the current behaviour of Helm which is not very supportive towards use in automated deployment pipelines.

The #7806 PR has been merged onto master. It will be released in 3.2. I am closing this issue accordingly.

Great! This solves most of our issues with Helm.
What is the current behavior if the first release fails though (no deployed releases yet)?
There was https://github.com/helm/helm/issues/3353 which was addressed by https://github.com/helm/helm/pull/3597 but only when --force is used.
--force has some issues in Helm 3 though (https://github.com/helm/helm/issues/6378), with a proposal to address it (https://github.com/helm/helm/issues/7082), plus as other comments in this thread mentioned, using --force is not always suitable anyway. So the whole situation is still somewhat unclear.

@technosophos thanks for the fix. Curious, when would 3.2. release available to install ? Keep getting app-name has no deployed releases error on an existing failed release. And it's kind a blocker in CI/CD pipelines.

@peterholak see #7913.

3.2 will be discussed on the April 16 public dev call. I have triaged it down to just the ones that currently look like they can be wrapped up right away. Then we will start the beta release process (assuming maintainers all agree on the call tomorrow).

I was facing the same issue on AKS solve to fix the mentioned issue by following command:
helm version : 3.1.2
I just delete the package from k8s cluster with command
 helm delete <release-name>
and run the deployment cycle to fix the issue

The issue is still there in 3.2.0 version

@deimosfr This is fixed in #7653 which will be in release 3.2.1. It is not yet released but you can get the fix if you want to build off master.

I'm on 3.2.1 and this is still happening

There are still reasons that this error can occur. 3.2.1 didn't simply remove the error. It removed some of the causes.  If you're still experiencing it, your problem is something other than what the issue corrected.

@yinzara I have a classic case of "path b" from the original description on a fresh cluster with no issues. I can also reproduce this error in another cluster where Helm v2 works just fine. We can of course do the classic "this is caused by something else, open a new issue", but I think it will be quicker if it's simply recognized that it's not really fixed.

What is the output of helm list?  What is the "status" of the prior failed release?

Still happens on version 3.2.1.
If the initial deploy fails 3 times it all gets stuck...No way to fix it if you don't delete the chart and deploy a good one.
Details:
helm history t3-mac -n t3                                                                                REVISION        UPDATED                         STATUS          CHART           APP VERSION     DESCRIPTION
1               Fri May 22 18:55:11 2020        failed          t3-mac-2.13.0   2.13.0          Release "t3-mac" failed: timed out waiting for the condition
2               Fri May 22 19:33:44 2020        failed          t3-mac-2.13.0   2.13.0          Upgrade "t3-mac" failed: timed out waiting for the condition
3               Fri May 22 19:57:51 2020        pending-upgrade t3-mac-2.13.0   2.13.0          Preparing upgrade

helm.exe upgrade --namespace t3b --install --force --wait t3b-mac t3b-mac-2.13.0.tgz
2020-05-22T18:14:01.7103689Z Error: UPGRADE FAILED: "t3b-mac" has no deployed releases

I have the same issue on deployed chart and the pod is running fine
vm-victoria-metrics-single-server-0                    1/1     Running     0          2d18h

But I can't upgrade it.

$ helm version
version.BuildInfo{Version:"v3.1.2", GitCommit:"d878d4d45863e42fd5cff6743294a11d28a9abce", GitTreeState:"clean", GoVersion:"go1.13.8"}

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-26T06:16:15Z", GoVersion:"go1.14", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.8", GitCommit:"ec6eb119b81be488b030e849b9e64fda4caaf33c", GitTreeState:"clean", BuildDate:"2020-03-12T20:52:22Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}

ismail ~ $ helm list
NAME	NAMESPACE	REVISION	UPDATED                             	STATUS  	CHART                                  	APP VERSION
vm  	default  	1       	2020-05-23 16:20:35.243505 +0300 +03	deployed	victoria-metrics-single-0.5.3          	1.35.6

$ helm upgrade vm vm/victoria-metrics-single --set "-selfScrapeInterval=10"
Error: UPGRADE FAILED: "vm" has no deployed releases

ismail ~ $ helm upgrade --install vm vm/victoria-metrics-single --set "-selfScrapeInterval=10"
Release "vm" does not exist. Installing it now.
Error: rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: namespace: , name: vm-victoria-metrics-single, existing_kind: policy/v1beta1, Kind=PodSecurityPolicy, new_kind: policy/v1beta1, Kind=PodSecurityPolicy

I confirm it happened on my side as well

@zodraz Your helm status shows the reason for your error. The most recent release isn't showing as failed, it's showing as "pending install". This would imply the process that was managing the last upgrade was artificially terminated before it completed (i.e. before it errored or was successful).
It was the decision of the project maintainers to not include the pending install status as a valid error status to allow the upgrade.  (i.e. this is working as designed)
I suggest you try to ascertain why your helm upgrade is being cancelled before it finishes.  That should be an avoidable situation.

I have the same issue on deployed chart and the pod is running fine
vm-victoria-metrics-single-server-0                    1/1     Running     0          2d18h

But I can't upgrade it.

$ helm version
version.BuildInfo{Version:"v3.1.2", GitCommit:"d878d4d45863e42fd5cff6743294a11d28a9abce", GitTreeState:"clean", GoVersion:"go1.13.8"}

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-26T06:16:15Z", GoVersion:"go1.14", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.8", GitCommit:"ec6eb119b81be488b030e849b9e64fda4caaf33c", GitTreeState:"clean", BuildDate:"2020-03-12T20:52:22Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}

ismail ~ $ helm list
NAME	NAMESPACE	REVISION	UPDATED                             	STATUS  	CHART                                  	APP VERSION
vm  	default  	1       	2020-05-23 16:20:35.243505 +0300 +03	deployed	victoria-metrics-single-0.5.3          	1.35.6

$ helm upgrade vm vm/victoria-metrics-single --set "-selfScrapeInterval=10"
Error: UPGRADE FAILED: "vm" has no deployed releases

ismail ~ $ helm upgrade --install vm vm/victoria-metrics-single --set "-selfScrapeInterval=10"
Release "vm" does not exist. Installing it now.
Error: rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: namespace: , name: vm-victoria-metrics-single, existing_kind: policy/v1beta1, Kind=PodSecurityPolicy, new_kind: policy/v1beta1, Kind=PodSecurityPolicy

I will say your issue is quite perplexing to me.  I can't see how that could have happened given the log output you have.  The fix release in 3.2.1 certainly won't help your situation as you don't have a failed release.  I would guess somehow some of the secrets got removed from Kubernetes that contain the helm release information.  I would suggest completely uninstalling the release and reinstalling if you can.

Hi @yinzara,
The thing is that I did not cancel it...As far I understand the thrird time I launched (and erroed...because I had errors on the deployments to make it succeed) made it to stay on a corrupted state...
This is state is not recoverable...So the only way to fix it is to delete the chart...My workauround to avoid this to use the atomic flag to rollback always and never reach this corrupted state...
I understand the decision of the maintainers...But this leads to confusion, no possible solution at all (if not deleting the chart) and well, like I said this state was reached when 3 errors happened...without cancelling it...
Anyway lesson learnt and making rollbacks through the atomic flag.

Hi @yinzara
I found the reason why it fails.
I set the wrong parameter -selfScrapeInterval=10 it should be  server.extraArgs.selfScrapeInterval=10
So the problem with - in the parameter.
Maybe the helm error was not meaningful for this type of variable error?
Failing one:

ismail sf $ helm upgrade vm vm/victoria-metrics-single --set "-selfScrapeInterval=10"
Error: UPGRADE FAILED: "vm" has no deployed releases

Success:

ismail sf $ helm upgrade vm vm/victoria-metrics-single --set "server.extraArgs.selfScrapeInterval=10"
Release "vm" has been upgraded. Happy Helming!
NAME: vm
LAST DEPLOYED: Tue May 26 22:35:15 2020
NAMESPACE: default
STATUS: deployed
REVISION: 3
TEST SUITE: None
NOTES:
TBD

This also works:
ismail sf $ helm upgrade vm vm/victoria-metrics-single --set "selfScrapeInterval=10"
Release "vm" has been upgraded. Happy Helming!
NAME: vm
LAST DEPLOYED: Tue May 26 22:37:43 2020
NAMESPACE: default
STATUS: deployed
REVISION: 4
TEST SUITE: None
NOTES:
TBD

I have the same problem :'(  and I can't use purge because I will lose the data and I can't do that, I know this issue is closed but only I'm expressing my pain.

We have to ditch helm releases, when we deploy critical workloads, even istioctl of istio ditches helm for this reason (I assume). We use helm template.... | kubctl -f - to avoid this issue, but this of-course creates issue having to remember about deleted resources.

@GloriaPG can you share more information? How are you experiencing the same problem? As @yinzara mentioned earlier in the thread, you may be experiencing an issue where #7652 does not capture. We need more information to help before we can come to that conclusion, however.

Hi @bacongobbler
We're using helm upgrade with --install and --force flags:
helm upgrade --install ${PROJECT_NAME} ${CHART_NAME} \
   --namespace $NAMESPACE_NAME \
   --values ${SECRETS} \
   --values ${CONFIG_VALUES} \
   --force \
   --wait \
   --timeout ${MAX_WAIT_SECONDS} || rollback

Unfortunately when release is in failed state:
$ helm list
NAME                 	NAMESPACE	REVISION	UPDATED                                	STATUS  	CHART       	APP VERSION
PROJECT_NAME              	CHART_NAME   	136     	2020-07-09 14:13:09.192381483 +0000 UTC	failed  	CHART_NAME-0.1.0

it result in:
Error: UPGRADE FAILED: "PROJECT_NAME" has no deployed releases
Error: failed to replace object: Deployment.apps "PROJECT_NAME" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app":"PROJECT_NAME"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable

How it can be solved? It seems that --force with --install flag is not working
As this is production env I'm not able to just purge release and create it from scratch :(
Thanks for any suggestions

You error seems to be related to https://github.com/kubernetes/client-go/issues/508
You cannot change the selector on a Deployment. You would have to undeploy and redeploy.

@yinzara the funny thing is that I'm not changing selector on my deployment, everything is working on 9/10 deployments. In one during deployment sth went wrong, release is in failed state and I'm not able to recover from it in any way - deployment itself is working, Pods are running but I'm no longer able to modify it.

Yeah unfortunately this doesn't actually seem to be a helm problem. Something failed about your release and it's in a bad state in kubernetes.  More than likely the selector is messed up or something is not as you expect, but the error you're seeing about "app-name" has no deployed releases is just a red herring.

I've tried rollback to previous version, release is now in deployed status. Unfortunately it doesn't change anything so I think the only way is to delete and deploy again unfortunately.

So, my particular issue with this is easy to reproduce.
Start deploying something with helm3 (with --atomic and --cleanup-on-fail), and ctrl+c the process after it starts creating resources. Nothing is rolled back, the resources still exist, and any subsequent attempts to run install --upgrade result in the "has no deployed releases" error.
This ctrl+c is something that in essence happens when someone pushes a new commit to a branch in our CI system while there's already a build running - the helm upgrade will get cancelled, and then it's in a completely broken state.
Is there something we can do to fix it after this point? As with many others in this thread, deletion is not an option.

Actually - nevermind. For those affected by this, there is one solution: delete the history record from kubernetes manually. It's stored as a secret. If I delete the offending pending-install state entry, then I can successfully run upgrade --install again!

@AirbornePorcine - Can you please elaborate on the changes required in kubernetes to delete the pending-install entries .

@tarunnarang0201 Helm creates a kubernetes secret for each deploy, in the same namespace you deployed to, you'll see it's of type 'helm.sh/release.v1', and named something like 'sh.helm.release.v1.release-name.v1'. You just have to delete the most recent secret (look at the 'v1' suffix in the example, it's incremented for each deploy), and that seemed to unblock things for me.

@AirbornePorcine thanks!

@AirbornePorcine @tarunnarang0201 @ninja- You can also just patch the status label (especially, if you don't have any previous DEPLOYED releases.
For Helm 3, see my comment at https://github.com/helm/helm/issues/5595#issuecomment-580449247
For more details and instructions for Helm 2, see my comment at https://github.com/helm/helm/issues/5595#issuecomment-575024277

This conversation is too long... and each comment has one solution .... what's the conclusion?
We've been using old helm 2.12 and we never had issues but now with v3.2.4 a previously failed deployment fails with this error.
We are using Terraform by the way and latest helm provider. So should we use --force or --replace

@xbmono The conversation is long because there are

there are quite a number reasons your release can get into this state
this was possible on Helm 2 as well, and solutions that worked there and on Helm 3 are different.
there are different paths users in this issue took to get there
there are different options depending on what you are trying to do, and whether you are willing to risk/tolerate loss of PVCs and various possible combinations of downtime.

If you are at a "has no deployed releases" error I'm not sure install --replace nor upgrade --install --force will help you on its own.
A sensible suggestion can probably only be given

if you supply the helm history for the release so people can see what has happened
if you share the original reason for the failure/what you did to get there - and whether you feel that the original problem been addressed

My summary of possible options

if you don't care about the existing k8s resources at all or downtime, helm uninstall && helm install may be an option
if it's a first time chart install that failed, you can probably just delete the release secret metadata and helm install again. Maybe will need to clean up k8s resources manually if cruft got left beyond due to the failure, depending on whether you used --atomic etc.
if you abandoned a --waited install part way through and the helm history shows the last release is in pending-install you can delete the most recent release secret metadata or patch the release status
in certain other combinations of scenarios, it may also be possible to patch the release status of one or more of the release secrets and see if a subsequent upgrade can proceed, however to my knowledge, most of these cases were addressed by #7653 (to ensure there is a deployed release somewhere in the history to go back to) so I'd be surprised if this was useful now.

Since this is a closed issue, I suspect there is a root cause that would be good to debug and document in a different, more specific ticket anyway.

@chadlwilson  Thanks for your response.
helm history returns no rows!
Error: release: not found

but helm list returns the failed deployment
M:\>helm3 list -n cluster171
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS  CHART                           APP VERSION
cluster171      cluster171      1               2020-09-01 04:45:26.108606381 +0000 UTC failed    mychart-prod-0.2.0-alpha.10    1.0

We are using Terraform and our environments get deployed every hour automatically by Jenkins.
In the terraform code I have set force_update to true, no luck and the I set replace to true, again no luck
resource "helm_release" "productStack" {
  name = "${var.namespace}"
  namespace = "${var.namespace}"
  chart = "${var.product_stack}"
  force_update = true//"${var.helm_force_update}"
  max_history = 10
  replace = true

  wait = true
  timeout = "${var.timeout_in_seconds}"

}

So I wonder if it's to do with wait=true ? So the reason the previous deployment failed was that the cluster wasn't able to communicate with docker repository and so the timeout reached and the status is failed but we fixed the issue and the pods restarted successfully, now obviously helm delete works but if I were to do this each time my managers nor the developers will be happy.
With helm v2 if the deployment fails and the developers fix it, the next deployment would upgrade the failed deployment.

M:\>helm3 list -n cluster171
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS  CHART                           APP VERSION
cluster171      cluster171      1               2020-09-01 04:45:26.108606381 +0000 UTC failed    mychart-prod-0.2.0-alpha.10    1.0

The helm history failure seems odd (typo? missed namespace? wrong helm version?), but given it's revision 1 in the list above it seems you are trying to do a first time installation of a new chart and the first time installation has failed. If you are trying to unblock things you can probably delete the release secret metadata as above or patch its status, and try again. That may indicate that the metadata is in a bad state from the perspective of either Helm or the Helm Terraform Provider, but not how it got there.
In any case, I don't have issues doing upgrade over failed first-time deploys with Helm 3.2.1 since #7653 was merged. You might want to double-check the specific Helm version the provider is actually using? It's also possible it may be to do with the way the Helm Terraform provider figures out the state of the release after an install failure. I don't have any experience with that provider, and personally am not in favour of wrapping Helm with another declarative abstraction such as TF because I find it even more opaque when things go wrong, but you might want to dig further there all the same.
In any case, as I said above, if the error you are stuck at is has no deployed releases after a failed first-time deployment, I don't think either replace nor force are likely to help you resurrect the situation without some other intervention and it would be best to debug it further and have any conversation elsewhere, as going back and forth on this old closed ticket with 51 participants doesn't seem so productive for all concerned.

Actually - nevermind. For those affected by this, there is one solution: delete the history record from kubernetes manually. It's stored as a secret. If I delete the offending pending-install state entry, then I can successfully run upgrade --install again!

Alternatively, this worked for me:
helm uninstall {{release name}} -n {{namespace}}

fixed by kubectl -n $namespace delete secret -lstatus=pending-upgrade
Run now helm again.

I am not sure why this is closed, I've just hit it with brand new Helm 3.3.4. If initial install fails, second helm upgrade --install --force still shows the same error.
Has anyone thought of simply adding a flag that this is the first release so it should be safe to just delete it automatically? Or adding something like "--force-delete-on-failure"? Ignoring the problem is not going to help.

@nick4fake AFIK it was closed by PR #7653. @yinzara might be able to to provide more details.

It was a decision by the maintainers to not allow overwriting a pending-upgrade release. But your statement that all work arounds are work aroundsthat don't work in a CI/CD pipeline are not true. The last suggested work around could be added as a build step before running your helm upgrade (i also would not use --force in a CI/CD pipieline). It has the same effect as what you've suggested.

I have also used the following in my automated build to uninstall any "pending" releases before I run my upgrade command:
RELEASES=$(helm list --namespace $NS_NAME --pending --output json | jq -r '.[] | select(.status=="pending-install")|.name')
if [[ ! -z "$RELEASES" ]]; then
  helm delete --namespace $NS_NAME $RELEASES
fi

@yinzara thank you for the snippet, it is very helpful for those finding this thread.
My point is still valid - it is not safe to simply delete release. Why can't Helm force-upgrade release if a single resource fails? Replacing release with a new version seems a better solution than full deletion. I might not understand some core fundamentals of Helm (like how it manages state) so it might be not possible to do, but I still don't understand why it is better force users to manually intervene if first installation fails.
I mean, just check this discussion thread, people still face the issue. What do you think about possibly adding some additional information to Helm error message with link to this thread + some suggestions on what to do?

@nick4fake I think you're mixing up "failed" with "pending-install".
The library maintainers agree with you about failed releases, that's why they accepted my PR.
A "failed" release CAN be upgraded. That's what my PR did.  If a release fails because one of the resources failed, you can just upgrade that release (i.e. upgrade --install works too) and it will not give the "app-name" has no deployed releases error.
You're talking about a "pending-install" release. The maintainers do not think it is safe to allow you to force upgrade a pending-install release as it could possibly be in progress still or be in a partially complete state that they don't feel can be resolved automatically.
If you find your releases in this state, you might want to reconsider your deployment configuration.  This should never happen in a properly configured CI/CD pipeline.  It should either fail or succeed. "pending" implies the install was cancelled while it was still processing.

That being said, I don't agree with your statement that your point is still valid.  My suggestion may remove the pending release, however @abdennour suggestion right before yours is just to delete the secret that describes the pending install release.  If you do that you're not deleting any of the resources from the release and can upgrade the release.

What do you think about possibly adding some additional information to Helm error message with link to this thread + some suggestions on what to do?

+1 to this. We still have to google around, to find this thread, to understand what's a pending-install release, so we can begin to reason about this error message.

For me this issue was a missing namespace. I added -n <namespace> and it worked.

For Helm3
kubectl -n <namespace> patch secret <release-name>.<version> --type=merge -p '{"metadata":{"labels":{"status":"deployed"}}}'
release-name and version - Can be seen from kubectl get secrets -n <namespace> | grep helm

if service type is loadbalancer and the status is pending, --atomic can eventually timeout if external IP is not assigned on-time.

if service type is loadbalancer and the status is pending, --atomic can eventually timeout if external IP is not assigned on-time.

For Helm 2, it can solved through:
kubectl -n kube-system patch configmap release-name.v123 --type=merge -p '{"metadata":{"labels":{"STATUS":"DEPLOYED"}}}'

the patch does not work anymore:
kubectl describe secret sh.helm.release.v1.test-1.v1
Name:         sh.helm.release.v1.test-1.v1
Namespace:    default
Labels:       modifiedAt=1634763779
              name=test-1
              owner=helm
              status=test
              version=1
Annotations:  <none>

Type:  helm.sh/release.v1

Data
====
release:  3100 bytes

and :
helm ls
NAME  	NAMESPACE	REVISION	UPDATED                             	STATUS  	CHART        	APP VERSION
test-1	default  	1       	2021-10-20 17:02:59.333187 -0400 EDT	deployed	mychart-0.1.0	1.16.0

the status is now elsewhere :
kubectl get secret sh.helm.release.v1.test-1.v1 -o json | jq .data.release | tr -d '"' | base64 -d | base64 -d | gzip -d | jq | grep status

good luck editing that base64 and replacing it.
We found no solution but to delete the secret.

something like this worked for us:

$ kubectl get secret sh.helm.release.v1.xxx.v123 -o json > secret.orig.json
$ cat helm-hackery/secret.orig.json | jq -r '.data.release' | base64 -d | base64 -d | gzip -d > secret.json

$ vi secret.json
<- change status to "deployed"

$ cat secret.json | gzip | base64 | base64 > secret.encoded
$ jq -r '.data.release = $input' secret.orig.json --rawfile input secret.encoded > secret.new.json
$ kubectl apply -f secret.new.json


Windows Installation tutorial has wrong cuDNN version requirement, 7 required for latest version.

Inaccuracies in the documentation.
In the installation documentation Tensorflow in Windows says that the system must be running a version of CUDA 9.0 (correctly) and cuDNN 6.0 (not correct) because on the Nvidia website we can download and install only:

cuDNN v7.0.5 , for CUDA 8.0/9.0/9.1 ;
cuDNN v7.0.4 , for CUDA 8.0/9.0 ;
cuDNN v6.0 , for CUDA 8.0 .

In https://developers.googleblog.com/2018/01/announcing-tensorflow-15.html said that

If you are using GPU Acceleration on Windows or Linux, TensorFlow 1.5 now has CUDA 9 and cuDNN 7 support built-in.

In issue #16477 (https://github.com/tensorflow/tensorflow/issues/16477)  as @gunan  said

Windows also requires cuDNN 7, looks like we missed that.

In proof of his words let me give you output logs:
(tensorflow15) C:\Windows\system32>python
Python 3.5.4 |Anaconda, Inc.| (default, Nov  8 2017, 14:34:30) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
import tensorflow as tf
Traceback (most recent call last):
File "C:\Users\User\AppData\Local\conda\conda\envs\tensorflow15\lib\site-packages\tensorflow\python\platform\self_check.py", line 87, in preload_check
ctypes.WinDLL(build_info.cudnn_dll_name)
File "C:\Users\User\AppData\Local\conda\conda\envs\tensorflow15\lib\ctypes_init_.py", line 351, in init
self._handle = _dlopen(self._name, mode)
OSError: [WinError 126] Не найден указанный модуль (The specified module was not found)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "", line 1, in
File "C:\Users\User\AppData\Local\conda\conda\envs\tensorflow15\lib\site-packages\tensorflow_init_.py", line 24, in
from tensorflow.python import *
File "C:\Users\User\AppData\Local\conda\conda\envs\tensorflow15\lib\site-packages\tensorflow\python_init_.py", line 49, in
from tensorflow.python import pywrap_tensorflow
File "C:\Users\User\AppData\Local\conda\conda\envs\tensorflow15\lib\site-packages\tensorflow\python\pywrap_tensorflow.py", line 30, in
self_check.preload_check()
File "C:\Users\User\AppData\Local\conda\conda\envs\tensorflow15\lib\site-packages\tensorflow\python\platform\self_check.py", line 97, in preload_check
% (build_info.cudnn_dll_name, build_info.cudnn_version_number))
ImportError: Could not find 'cudnn64_7.dll'. TensorFlow requires that this DLL be installed in a directory that is named in your %PATH% environment variable. Note that installing cuDNN is a separate step from installing CUDA, and this DLL is often found in a different directory from the CUDA DLLs. You may install the necessary DLL by downloading cuDNN 7 from this URL: https://developer.nvidia.com/cudnn
In conclusion.
Need to replace:

cuDNN  v6.0. For details, see NVIDIA's documentation. Note that cuDNN is typically installed in a different location from the other CUDA DLLs. Ensure that you add the directory where you installed the cuDNN DLL to your %PATH% environment variable.

to

cuDNN v7.0. For details, see NVIDIA's documentation. Note that cuDNN is typically installed in a different location from the other CUDA DLLs. Ensure that you add the directory where you installed the cuDNN DLL to your %PATH% environment variable.

on the web page https://www.tensorflow.org/install/install_windows

This looks to me like it's been fixed in the repository.
https://github.com/tensorflow/tensorflow/blob/master/tensorflow/docs_src/install/install_windows.md
Please reopen if I've misread things.

And @nikitaverbis, thanks for reporting this!


Internal endpoint for invoice webhook

Can lnbits invoice api do an internal webhook?
I have tried this in all different shapes and sizes and I cant get it to hit the endpoint. The endpoint its trying to hit works perfectly. I thought it might be because I am trying to do an internal endpoint?
https://github.com/lnbits/lnbits/blob/05317eb5d6ab8175ee64f6fac935c9afc3d3816f/lnbits/extensions/copilot/lnurl.py#L74

Internal endpoints should work if the invoice listeners thing is working. Have you tried sending the webhook to somewhere else to see if it goes? What funding source are you using? If it's LNPay you'll have to manually enable webhooks from the LNPay dashboard. Try using lnbits.com as the funding source for your local LNbits, it works (rebase to master before).
Sending webhooks internally it's interesting solution though, I hadn't thought about it -- but I recommend using the internal "listener" thing. See https://github.com/lnbits/lnbits/blob/05317eb5d6ab8175ee64f6fac935c9afc3d3816f/lnbits/extensions/subdomains/tasks.py#L14-L40, for example (similar code also exists on lnurlp, offlineshop, livestream).

Wow, thanks! I'd hit a wall, this gives me plenty to go on👍
Its the final bug that needs to be squished.
I'm running on lntxbot, which I know handles webhooks out of the box

Oh, ok. Then it should be working, but lntxbot is so buggy someone has to complain to their developer.
I recommend testing the webhook to somewhere else first then.

Found a way around it, so closing


Swift Package Manager Support

I couldn't find any info on the README about swift package manager support (and didn't see a Package.swift file either). Is there any particular reason for that? Just wasn't looked into or is there a bigger issue?

Would be great to have SPM support. Tried it with a fork but this would result in a major refactoring and didn't want to go too far without asking the maintainer. I guess as SPM currently does not allow Objective-c and Swift files to be mixed.
Are you planning to add SPM as a further dependency manager?

Hey @ataias
I tried migrating the project to SPM in my fork but get a lot of Could not find issues. I am uncertain if we can fully migrate the framework but if you have time to have a look into it I would highly appreciate it.
So far what I found out is that the Objective-c part is dependent on the Swift part due to the ClosureContainer and I needed to separate the Objective-C and Swift files as SPM does not support mixed language dependencies. I then made a separate target for the Objective-C code and added it as a dependency to the Swift target resulting in a missing ViewControllerPresentationSpy-Swift.h file due to the Objective-C part not having a Swift file which is required to generate to do so.
I am kind of stuck here and help would be highly appreciated. Please share your thoughts or maybe @jonreid has any experience with mixed language projects being available with SPM.
Thank you very much in advance.

My guess is that I should rewrite the original Objective-C implementation into Swift. That'll solve things for most folks using SPM, because most of them are probably using Swift. Will this "just work" for Obj-C, or will we need a thin wrapper? Don't know until we get there.

Thanks for your reply Jon. I would highly appreciate your work on rewriting the framework into Swift.
If I am of any help let me know.
Looking forward to seeing your great work.

Hi, any updates regarding SPM?
Thankyou

I just started live-coding the work needed at https://twitch.tv/qcoding

I've begun the conversion as a live-coding project on Twitch.
https://www.youtube.com/playlist?list=PL-NrXVEjQ-o8grWHkuyeDk1TZN--VwX7m

I've begun the conversion as a live-coding project on Twitch. https://www.youtube.com/playlist?list=PL-NrXVEjQ-o8grWHkuyeDk1TZN--VwX7m

thanks in advance, Jon

Now available!


delete non-existing gateway on node returns 204 instead of 404

scenario

create gateway gw1 on node1
call api DELETE /nodes/{{node2}}/gws/{gw1}}

expected result

api response should be Not found as gw1 not exists in node2

actual result

gw1 will be deleted

Deletion of non-existing resources should indeed return 204, since the desired outcome is achieved. This is proper design.


A possible option to have ESC exit the switcher?

Canceling out of an action without performing it is an important part of any UX, I'd really appreciate this as an option in the config.
There's an autohotkey version of this (https://github.com/Osmagtor/AppSwitcher/ - I modified it and posted my changes in the "issues" - but I'm not the best at it. I'd prefer to use this Rust version, if it could exit when I press Esc - as that's what I use when I work on my Mac at home :)
Thanks for making this regardless!

The switch-app GUI, activated by pressing Alt+Tab, remains visible only while the Alt key is held down and disappears upon its release.
There is no need for additional ESC exit.
In addition, This tool's most notable feature is its speed and simplicity. It has only two hotkeys（as promised in the readme):

Alt+Tab to switch between apps
Alt+` to switch between windows of the same app

No additional shortcut keys or functions are planned for the foreseeable future.

Thank you still, it's an awesome app.
The switcher switches to the highlighted app when I release "alt", and then exits.
The proposed "esc" press would only exit the switcher, and not make the switch to the app.
I do appreciate your firmness on keeping this App minimal, could you perhaps give me a pointer what line(s) I'd need to go to / alter to fork it and put this in myself? Much obliged.

Hey! I see I missed some notifications, I just wanted to say: thank you for this 🙏


chore(build): ignore build artifacts

Add npm and rails build artifacts to .gitignore to ease from source / dockerless deployments

Coverage: 87.591%. Remained the same when pulling 2ea2aa338212ca643b5cf3def66648f7a36da80b on syrosh:chore/ignore-build-artifacts into 4a028b440be2318fbbcc7ae8a56faaa2a11f6d0a on CentauriSolutions:main.


Can't add a pull image secret to ActiveMQArtemis initImage

When I public the initImage on a private registry, I can't add also a pull image secret so I'm not authorized to pull the image.
To Reproduce
Steps to reproduce the behavior:

Add a custom initImage to a private registry
Define a yaml file to configure an ActiveMQArtemis broker and set the initImage url to define custom configurations
Try to pull the image from the private registry. I'm not authorized (no image pull secret is defined)

Platform:

OS: Linux
Version Ubuntu 20.04
Go 1.17.6

Expected behavior
I would like to define the initImage and also a pull image secret in the ActiveMQArtemis definition

@paolabassi this issue makes sense to me, are you planning to contribute with a pull request?

@paolabassi this issue makes sense to me, are you planning to contribute with a pull request?

No, I’m sorry. I abandoned the use of the operator because it currently has too many limitations

@brusdev we've been hit by the same issue. if you can provide a rough guideline on where to add what i can take a stab at providing a pull request.

@naude-r I would add the ImagePullSecrets field to the DeploymentPlanType struct that the ActiveMQArtemisReconciler could use to fill the field ImagePullSecrets of podSpec.

@brusdev thanks. will take a look.

Are you using go 1.17?

yes.
activemq-artemis-operator]$ go1.17 version
go version go1.17 linux/amd64

Makefile was updated to use go1.17

yes.
activemq-artemis-operator]$ go1.17 version
go version go1.17 linux/amd64

Makefile was updated to use go1.17

got it working. had to remove all previous go packages from a newer version.

PR #582 added.

@naude-r thanks, I have added some comments to your PR #582

This enhancement will be included in v1.0.12