Channels
announcements
automation-api
aws
azure
blog-posts
built-with-pulumi
cloudengineering
cloudengineering-support
content-share
contribex
contribute
docs
dotnet
finops
general
getting-started
gitlab
golang
google-cloud
hackathon-03-19-2020
hacktoberfest
install
java
jobs
kubernetes
learn-pulumi-events
linen
localstack
multi-language-hackathon
office-hours
oracle-cloud-infrastructure
plugin-framework
pulumi-ai
pulumi-cdk
pulumi-cloud
pulumi-crosscode
pulumi-deployments
pulumi-kubernetes-operator
pulumiverse
python
registry
status
testingtesting123
testingtesting321
typescript
welcome
workshops
yaml
Title
b
billowy-army-68599
04/23/2021, 4:53 PMhi community! would love to get some thoughts about Pulumi packages here:
https://twitter.com/briggsl/status/1385632978504613890?s=20
b
better-shampoo-48884
04/24/2021, 11:24 AMThis 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:
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
kind-mechanic-53546
04/27/2021, 11:35 AMReplied 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
fresh-pilot-59899
04/28/2021, 7:10 AMb
better-actor-92669
04/29/2021, 9:29 AMhttps://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
better-shampoo-48884
05/02/2021, 9:49 AMJohnB - 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)