-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Helm lookup Function Support #5202
Comments
Note that even if we allowed configuring Argo CD to append the Since you would anyways need a customized repo-server, you can already accomplish this today using a wrapper script around the |
@jessesuen, I guess this workaround is possible only with in-cluster configuration, and wont work for the external ones. |
Ah yes, you are right about that unfortunately. |
@jessesuen just coming across this issue and I'm running into the same. There is duplicate issue here as well: #3640 You mentioned two things to accomplish as a work around for Argo not supporting this:
Can you expand more on the wrapper script? How would one inject that into a standard Argo deployment? |
Hi @jessesuen, @Gowiem, any updates on this? Thanks in advance, Dave |
@dvcanton I tried the Argo plugin / wrapper script approach that @jessesuen mentioned after asking about it directly in the Argo Slack. You can find more about that by looking at the plugins documentation. Unfortunately, that solution seemed overly hacky and pretty esoteric to me and my team. Instead we've now moved towards not using |
A lot of charts use build-in objects such as Capabilities to provide backward compatibility for old APIs. Capabilities.APIVersions works properly only with --validate flag because without this flag it returns only API versions without available resources. |
As about Capabilities, |
@kvaps take a look for an example which I posted. |
@randrusiak, it works to me: # helm template . --set ingress.enabled=true --include-crds > /tmp/1.yaml
# helm template . --api-versions networking.k8s.io/v1/Ingress --set ingress.enabled=true --include-crds > /tmp/2.yaml
# diff -u /tmp/1.yaml /tmp/2.yaml
@@ -399,7 +399,7 @@
emptyDir: {}
---
# Source: grafana/templates/ingress.yaml
-apiVersion: extensions/v1beta1
+apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: RELEASE-NAME-grafana
@@ -417,9 +417,12 @@
paths:
- path: /
+ pathType: Prefix
backend:
- serviceName: RELEASE-NAME-grafana
- servicePort: 80
+ service:
+ name: RELEASE-NAME-grafana
+ port:
+ number: 80 my idea was that ArgoCD could provide repo-server list of api-versions from destination Kubernets API. eg:
will return all available apiversions for the cluster. Not sure if lookup function support can be implemented with the same simplicity, as it already requires direct access to the cluster. |
@kvaps I understand how it works on the helm level, but I don't know how to pass this additional flag |
Actually my note was more likely for contributors than for users :) On current stage, I think you got nothing to do. The only workaround for you is to add serviceAccount to your repo-server and use Another option for you is to hardcode those parameters somewhere, eg. save the output of the following command:
And pass it to helm, using any suitable way for you, eg, you can still use wrapper script for cat /usr/local/bin/helm
#!/bin/sh
exec /usr/local/bin/helm.bin $HELM_EXTRA_ARGS "$@" where:
or using custom-plugin |
We also ran into the issue with the non-working lookup function. Background is that we want to make sure that for a certain service, a secure random password is generated instead of having a hardcoded default. If desired, the use can explicitly set his own password, but most people don't. Our goal is to keep the helmchart usage as simple as possible and require as little parameters for simple installations. So I would like to keep the "generate a secure (and stable) random password" as the default for "pure" Helm usage. |
Any update on this issue? |
Ran into this same problem today :( more context in https://cloud-native.slack.com/archives/C01TSERG0KZ/p1635024460105000 |
Same thing happens with aws-load-balancer-controller's mutating webhook that defines tls key, cert and CA: |
Ran into this today :( Do you have any timeline when the lookup will be available? |
It looks like you have overseen my question so I wanted to ask again. Is there any plan to get this in and when? |
I run into the same issue, but maybe the lack of this function is a good reason to move to the fluxv2, which already supports it |
FYI, this project provides a decent workaround https://github.com/kuuji/helm-external-val |
I think the main reason this is not a feature already is related to security, not the howto itself. Still a nice trick to work around it, if you need to have this working now. |
Yep, granting the repo-server full k8s access is a non-starter upstream. We need a way for the user to safely grant the repo-server temporary access to only the necessary subset of resources. imo, Project-level service account impersonation (for which there is a WIP PR) would be a huge step towards unblocking that access. I'll offer that, in my opinion, Helm lookups are a GitOps anti-pattern. But I do understand that we shouldn't make the perfect the enemy of the good. |
What other options are there, other than helm templating using lookup, to grab values from configmaps/secrets and use them in resources like ingress/service (other than saving them in the values file ofc :) ) ? Maybe there's a better option somewhere out there already.... |
We went with terraform Data sources, saving the outputs to git files, which are used as extra value files in Argo-cd. |
But that's like having your secret values in both the terraform state and a values file, right ? At this point, why not just save it directly in an extra values file ? |
Nothing of those are sensitive values. |
fwiw, since some use cases are being mentioned here, a use case that we'd like to use the lookup function for is to create resources like VPCs using the AWS ACK controllers, use its functionality to write a configmap with the newly created resource IDs, and feed those values into other charts that need the VPC or Subnet IDs (e.g., the elasticache chart). |
That particular example seems to fit much better in using labels and annotations in the vpc and subnet and let other resources find them |
Not all CRDs support looking up the live resources from the cloud nor the nice vpcRef sort of thing that the ACK controllers do. e.g., the cluster-api cluster resources need the VPC ID as a hardcoded string in the spec. :/ |
For charts that only accept these things via values or lookups, there is no other option. I'd suggest that those charts should be changed to support things like In general I think there are three ways to separate the concerns of app manifests from relevant external state:
|
That's what we currently have in our setup. It works, it's just more brittle than a simple helm lookup.
interesting idea. I hadn't thought of that. Not sure it'd work with argocd's self healing but it's definitely worth looking into.
ah how I wish all controllers worked this way. :) |
We do this with kyverno. It was our approach after trying shared configmaps. But for most of the stuff we used it early, we replaced it with the terraform approach I mentioned earlier. |
temporary fix for argocd issue argoproj/argo-cd/issues/5202
temporary fix for argocd issue argoproj/argo-cd/issues/5202
This reverts commit 8e7c17b.
This reverts commit 8e7c17b.
Revert "temporary fix for argocd issue argoproj/argo-cd/issues/5202"
Hello,
Happy new year Guys !!
So, I have this requirement to build the imagePath by reading the dockerRegistryIP value from configMap, so that I need not ask user explicitly where the registry is located.
Helm3 has introduced support for this where they introduced a lookup function through which configMap can be read at runtime like this,
{{ (lookup "v1" "ConfigMap" "default" "my-configmap").data.registryURL}}
But the lookup function will return nil when templates are rendered using "helm dryrun" or "helm template" as a result when you parse a field on nil, you will see an exception like this,
"nil pointer evaluating interface {}.registryURL Use --debug flag to render out invalid YAML"
The solution which was proposed on stack overflow is to use "helm template --validate" instead of "helm template"
Can you guys add support for this ?
Right now am populating docker-registry-ip like this, but with this kustomize-plugin approach am loosing the ability to render values.yaml file as an config screen through which user can override certain values i.e. the fix to solve one issue has lead to an other issue
The text was updated successfully, but these errors were encountered: