Unable to use helm CLI against helm releases that have been deployed by ArgoCD

[ghost]

Describe the bug
I'm unable to list or interact with my helm releases with helm CLI when they have been deployed using ArgoCD.

To Reproduce
Create helm app in ArgoCD :

argocd app create helm-guestbook \
  --repo https://github.com/bdelagesap/argocd-example-apps.git \
  --path helm-guestbook \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace helm-guestbook

Confirm app has been created :

argocd app get helm-guestbook
Name:               helm-guestbook
Project:            default
Server:             https://kubernetes.default.svc
Namespace:          helm-guestbook
URL:                https://localhost:8080/applications/helm-guestbook
Repo:               https://github.com/bdelagesap/argocd-example-apps.git
Target:             HEAD
Path:               helm-guestbook
Helm Values:        values.yaml
Sync Policy:        Automated (Prune)
Sync Status:        Synced to HEAD (7004f3e)
Health Status:      Healthy

GROUP  KIND        NAMESPACE       NAME            STATUS  HEALTH
       Service     helm-guestbook  helm-guestbook  Synced  Healthy
apps   Deployment  helm-guestbook  helm-guestbook  Synced  Healthy

Try to list or inspect the release :

helm list
null

helm status helm-guestbook
Error: getting deployed release "helm-guestbook": release: "helm-guestbook" not found

Confirm the deployment is actually there with kubectl :

k get deployments -n helm-guestbook
NAME             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
helm-guestbook   1         1         1            1           20m

Expected behavior
I should be able to use the helm CLI to list or interact with my helm releases that have been deployed in my cluster by ArgoCD.

Version

argocd version
argocd: v1.0.1+5fe1447.dirty
  BuildDate: 2019-05-28T17:28:05Z
  GitCommit: 5fe1447b722716649143c63f9fc054886d5b111c
  GitTreeState: dirty
  GoVersion: go1.11.4
  Compiler: gc
  Platform: darwin/amd64
argocd-server: v1.0.1+5fe1447.dirty
  BuildDate: 2019-05-28T17:27:38Z
  GitCommit: 5fe1447b722716649143c63f9fc054886d5b111c
  GitTreeState: dirty
  GoVersion: go1.11.4
  Compiler: gc
  Platform: linux/amd64
  Ksonnet Version: 0.13.1

helm version
Client: &version.Version{SemVer:"v2.14.0", GitCommit:"05811b84a3f93603dd6c2fcfe57944dfa7ab7fd0", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.14.0", GitCommit:"05811b84a3f93603dd6c2fcfe57944dfa7ab7fd0", GitTreeState:"clean"}

[alexec]

Hi - We use install Helm to install the applications but delete it afterward. You won't be able to use the helm CLI tool to work with apps. Instead, you can use the argocd and kubectl CLI tools.

[ghost]

@alexec Thanks for the clarification. This is expected behaviour.
I will close this issue then.

[abdennour]

This is a critical issue BTW !

Seems like Argo uses Helm as generator of YAML manifests only thru helm template.
Please be advised that helm template is not aware about the server side namely if your helm chart has some conditions based on the existence of API Versions Capabilities.

Similar GH issues:

• Add ability to pass Capabilities.APIVersions to template and lint helm/helm#3377
• .Capabilities.APIVersions is wrongly evaluated #3631
• Helm 3: diff looks like .Capabilities.APIVersions.Has always false databus23/helm-diff#165

[Xtigyro]

+1

[jsoref]

@abdennour, that may have been the case when this issue was filed, but I think it was resolved by #3243

[Xtigyro]

@jsoref This is still an issue. Tested it a few weeks ago with ArgoCD v2.0.0.

[jsoref]

@Xtigyro: this is ambiguous. The original issue is a complaint that one can't use helm to ask about what charts are deployed, and that's a design choice. The answer should be whatever you specified in git(ops) / ask argocd using argocd cli or browser to the argocd web app.

But, @abdennour 's comment was resolved ~2 months after it was made.

[Xtigyro]

@jsoref I need to ask for clarification.

A design choice is the Helm releases deployed with ArgoCD not to be listed thru, e.g., helm ls?

[jsoref]

Correct, per #1672 (comment) and accepted by the reporter in #1672 (comment)

[Xtigyro]

Okay - thanks for the reply.

[gadiener]

Hey @jsoref 👋🏻

Out of curiosity, what is the reason behind this design choice? Can't we achieve the same using helm upgrade --install instead of helm template (if that is how ArgoCD uses Helm behind the scene)?

I think that will give more flexibility to those who, like me, have other tools built on top of Helm working on the same releases deployed with ArgoCD. This design choice forces us to use Helm only for "templating" while other use cases exist.

To me, it seems like a breaking feature. I'm curious to hear what others think.

[jsoref]

I'm not the person who made the choice. But the idea is that ArgoCD owns the resource, so if you want information about it, you should be using the ArgoCD system. That could be looking at the git configuration to see what you asked for, or the ArgoCD ui/cli to see how synced the git state is with the kubernetes deployment.

If you want to upgrade a resource, edit the git configuration for the resource and wait for ArgoCD to apply your changes.

If the resource was visible to helm, there's a risk of someone trying to upgrade the resource manually using helm. That would then be overwritten by ArgoCD, which is tasked with owning the resource.

If you don't want to use ArgoCD to own a resource, then don't give it a resource in the first place.

[gadiener]

I see, but to be honest, I don't see any bad with that.

Wouldn't that be the same behavior if someone change a resource directly with kubectl?

I understand how ArgoCD owns the resource but, at the same time, it is not the only system using/managing it. There are cases where an operator in the cluster can touch a resource deployed with ArgoCD. The expected behavior would be that ArgoCD reverts any change if configured in auto-sync.

I don't get why precluding that from happening with Helm. That should be a user's choice. In my opinion, that limits how we can use Helm in combination with ArgoCD with not much benefit.

[jsoref]

Frankly, this is a closed ticket that you're hijacking. Use a discussion or Slack or something.

Kubectl can make a single change, and ArgoCD will stomp on it too. The amount of damage you're likely to experience from that is much lower than using helm and being surprised by the huge jitter you'd get.

[tyriis]

@gadiener have started a discussion on this topic here: #7759 but obviously, the interest to change it is really limited :/

[gadiener]

Yeah @tyriis, it's sad to see that. This would open the project to a wide range of new use cases

[VanTigranyan]

@alexec Can this be added in the official docs? I tried to find this information there but didn't find it, and I think this is an important piece of information that users should be aware of.

[HummingMind]

@alexec Can this be added in the official docs? I tried to find this information there but didn't find it, and I think this is an important piece of information that users should be aware of.

it is in the official docs. It's one of the FAQ:
https://argo-cd.readthedocs.io/en/stable/faq/

[smeredith84]

So you mean you guys delete all the release history and then don't even keep it yourself in your own internal data for us to query? So i can't get a history or my releases via the tool you're using helm because umm you delete it ?Then we are left without release history? I need to qeuery the timestamps between my historical helm releases based on version and build telemetry. How can we use argo and get that info beside crappy post sync hooks which will only get my future data?

[crenshaw-dev]

@smeredith84 Argo CD uses Helm to render manifests, but not for any of its release management capabilities. Argo CD has its own release history feature which is completely separate from Helm's. Argo CD also produces events and integrates with notifications engine for improved change tracking.

Please refrain from referring to Argo CD features as crappy, even the crappy ones. 😉 People are generally willing to help to solve problems (for free), but they're less inclined to do so when the conversation involves biting language.

[smeredith84]

i overreacted apologies lol. It seems we can collect this info via kubectl get applications -n argocd and then iterating across these objects parsing out release sequences. I'll admit post sync hooks aren't crappy and i love argo! Using an LLM to parse it its not even a hassle to decern all the release dates and time between them. Would be cool if you guys offered aggregating releases over time and provide a release cadence visualization of chart version over time!