hi community! would love to get some thoughts abou...
# kubernetes
b
hi community! would love to get some thoughts about Pulumi packages here: https://twitter.com/briggsl/status/1385632978504613890?s=20
b
This sounds brilliant! Only one I would add is the fluentd/fluent-bit (I also use mongo, redis, grafana and influx from the bitnami helm repo - but that's not as "official" as the fluent chart). Regardless - I'm hoping (begging) for this to be the first step of a "crd2pulumi" style converter.. +100 votes for "helm2pulumi" conversion 😄
Oh! And Falco:
Copy code
falcosecurity: {
            name: "falcosecurity",
            url: "<https://falcosecurity.github.io/charts>"
        },
Crap.. now you got me thinking.. maybe cert-manager? and if you actually think about making this a first-class-pulumi-maintained-provider-type-thing - the absolute Holy Grail of that would be Istio (though I would definetely prefer the operator method to the helm version, but hey)
I think for this stuff the greatest value is the lowest-level stuff - things in the monitoring/metrics area, networking and ingress, certificate management, secrets management - that kind of stuff. The next level up would be things like databases and suchlike, and finally the "added value" type charts for things like Argo and suchlike. The lower to "fundamental infra" you go the better the fit and the more likely the adoption.
k
Replied in thread On helm, is this the "best" way forward for complex deployments? I'd love to see a plain yaml solution baked into pulumi but don't know exactly how that would work. Reason I ask is I've actually started exporting from helm, committing yaml then applying the config via pulumi
f
b
https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack It is a bit tricky to install that chart now, because I have to use around 5 transformations to make it work 🙂 However, I think the chart quite useful and should be popular
b
JohnB - thats essentially how the helm provider in pulumi works. And I think Jaxx is hinting that this isn't really working too well (I myself have an issue that can only be debugged if i get access to the intermediate yaml from helm->k8s) - so pre-packaging helm deploys as native pulumi ones sounds really sensible to me (i.e. instead of using helm to manage the variables, convert that to pulumi code and you can treat the helm chart as a resource in pulumi directly)