#helm (2020-11)
Archive: https://archive.sweetops.com/helm/
2020-11-06
Is there any way to get the pre-rendered YAML and/or rendered JSON, as these are troubling to debug.
Error: YAML parse error on dgraph/templates/zero/svc.yaml: error converting YAML to JSON: yaml: line 15: did not find expected key
helm.go:84: [debug] error converting YAML to JSON: yaml: line 15: did not find expected key
YAML parse error on dgraph/templates/zero/svc.yaml
helm.sh/helm/v3/pkg/releaseutil.(*manifestFile).sort
/home/circleci/helm.sh/helm/pkg/releaseutil/manifest_sorter.go:146
helm.sh/helm/v3/pkg/releaseutil.SortManifests
/home/circleci/helm.sh/helm/pkg/releaseutil/manifest_sorter.go:106
helm.sh/helm/v3/pkg/action.(*Configuration).renderResources
/home/circleci/helm.sh/helm/pkg/action/action.go:159
helm.sh/helm/v3/pkg/action.(*Install).Run
/home/circleci/helm.sh/helm/pkg/action/install.go:238
main.runInstall
/home/circleci/helm.sh/helm/cmd/helm/install.go:229
main.newInstallCmd.func1
/home/circleci/helm.sh/helm/cmd/helm/install.go:117
github.com/spf13/cobra.(*Command).execute
/go/pkg/mod/github.com/spf13/[email protected]/command.go:842
github.com/spf13/cobra.(*Command).ExecuteC
/go/pkg/mod/github.com/spf13/[email protected]/command.go:950
github.com/spf13/cobra.(*Command).Execute
/go/pkg/mod/github.com/spf13/[email protected]/command.go:887
main.main
/home/circleci/helm.sh/helm/cmd/helm/helm.go:83
runtime.main
/usr/local/go/src/runtime/proc.go:203
runtime.goexit
/usr/local/go/src/runtime/asm_amd64.s:1357
It’s like What key? What was the YAML going into JSON? Staring at chart for hours, cannot spot issue.
@Joaquin Menchaca You’re looking for template
.
You can also comment out some yaml that is templated and it will still render, so you can not botch the result and you’ll see it as comments and be able to spot what is wrong.
I do, but sometimes they get very elusive. If I can see it happen, like the converted yaml to json, see the bad json, I would know immediately, a-ha, that’s where the bug is. The output about line numbers in JSON for the JSON you cannot see is not very helpful.
Oh yeah — That. You could use template
and redirect it to pbcopy
if you’re on mac and then paste it into a YAML to JSON converter.
Also, yq
or jq
probably take in Yaml and then output JSON.
They might be able to give you a better error / insight.
Won’t it fail at helm template if there’s an error, such as .Values.somevalue.value not set.
Yeah, that’s a holdup I guess. Theres gotta be an article written on debugging helm templating — It’s a pain.
I inherited a chart, that has a bug in it, if they set one value enable=false, it breaks. I spent hours trying to cut out parts to see if I can reproduce, but I could never find the bug.
2020-11-08
2020-11-17
Hi, could you make cloudposse/prometheus-to-cloudwatch available in helm repo? That will make keeping my chart installation up-to-date little easier. (Moved from #general)
Are you using #helmfile by anychance?
In that case, it’s very easy to install from any git repo
additionally, there’s a helm-git
plugin that accomplishes the same.
(just saying because I don’t think we’ll get around to this anytime soon, but this is what we do when we need a chart that isn’t published)
2020-11-18
hey folks, long time fan of cloudposse, first time poster.
i’ve been digging around for an openvpn implementation to run in k8s (EKS 1.16, specifically) and stumbled upon this: https://artifacthub.io/packages/helm/cloudposse/openvpn
it was republished on Oct 22nd, but still uses extensions/v1beta1
instead of apps/v1
API versions for deployments. it also has a dependency on this chart:
https://artifacthub.io/packages/helm/cloudposse/route53-kubernetes
republished on Oct 22nd as well, which also uses extensions/v1beta1
instead of apps/v1
in addition the openvpn chart relies on a Github-PAM module to offer OAuth, which seems to no longer exist, or was possibly renamed to: https://artifacthub.io/packages/helm/cloudposse/github-authorized-keys itself republished on Oct 22nd
succinctly, i guess my question is: am i on a wild goose chase if i try to unravel how to use all this?
A Helm chart for OpenVPN
Map k8s services to route53 domains
Use GitHub teams to manage system user accounts and authorized_keys. WARNING: * We recommend that you install this chart into the kube-system
namespace. * There should only be one installation per cluster (other releases will fail because of name conflict)
For what it’s worth, you guys rule. Although several parts were a little rusty, this solution is now running on EKS 1.16 with a few tweaks and upgrades here and there.
A Helm chart for OpenVPN
Map k8s services to route53 domains
Use GitHub teams to manage system user accounts and authorized_keys. WARNING: * We recommend that you install this chart into the kube-system
namespace. * There should only be one installation per cluster (other releases will fail because of name conflict)
cloudposse strikes again
Hey @froch! glad to have you here
Sooooo I think we’d accept any PRs to update this
(we don’t have it deployed anywhere right now to verify)
…but yes, you might be on a wild goose chase
We’re using Teleport most of the time these days
also, avoid route53-kubernetes
and use external-dns
instead
yessir! went down that road. saw the wearemolecule
folks deprecated in favor of external-dns
, which we were already running in our clusters. to get the first version of openvpn up and running, decided to keep route53-kubernetes
, but we’re removing it in favor of the latter
it’s definitely my intention to contribute back to this; we were using teleport until recently, but moved away from it. it was a very nice tool, but what usage we were making of it didn’t warrant the price tag
your terraform modules have saved me many a time, it would be my pleasure to send you back some love
Thanks @froch - totally makes sense.
Btw, we also support Pritunl
you might like that more?
ahk, looks like we haven’t published it yet. we can do that though if you’re interested
Comprehensive Distribution of Helmfiles for Kubernetes - cloudposse/helmfiles
2020-11-20
2020-11-24
2020-11-25
We’ve started experiencing
Error: looks like "<https://charts.bitnami.com/bitnami>" is not a valid chart repository or cannot be reached: read tcp x.x.x.x:59030->x.x.x.x:443: read: connection reset by peer
quite often recently. Probably it’s due to the fact that after the deprecation many people switched to their repos
If you still use charts from the old Google stable repos… their new location is: https://charts.helm.sh/stable
There are many charts that are either not ported to anywhere else or the changes between the charts in stable and the charts in new repos are very large and would require some hefty re-engineering.