https://pulumi.com logo
Join Slack
Powered by
Looking at the chat history… There’s some ambivale...
# general
p
Looking at the chat history… There’s some ambivalence about supporting Helm-based deployments. I’d really like that to work well (and be supported in Python). We’re still evaluating Pulumi, but a really attractive part of Pulumi for me is that I can see how it’d enable us to transition from our current state (helm charts and other nonsense) to Pulumi being the new glue code that’s pulling in those per-service helm charts, to the glorious ideal state where the helm charts are replaced by Pulumi programs.
g
@powerful-elephant-53462 There’s quite a bit of work in flight right now related to improving multi-language support in pulumi. We do plan to get the python support for k8s up to parity with the TS support soon as well. I agree that the ideal end state is managing resources natively with pulumi, but helm and yaml are important considerations for people with existing k8s workflows. I guess the short answer is: we’re actively working on it! 🙂
BTW, there’s also work in progress for being able to import existing k8s resources on a live cluster and then manage them with pulumi.
p
Great! Thank you!
c
@powerful-elephant-53462 the truth is that the ambivalence is less related to “should we support helm” and more related to helm doing things that cause users to have a bad experience.
For example, if you look through the open issues, you’ll see that ~all helm charts that generate random default secrets (even WordPress, one of the most popular ever) will always re-generate the secret, every time you apply the chart.
This causes distress and consternation for our users, because we tell them that this is happening, and they don’t like it. This leads to a bad experience because it’s not clera initially whether Pulumi is doing this itself or not — surely helm can’t be doing stuff like this by default, right?
Our reticence here is NOT because we don’t want to support it, it’s because I do not want to be in the game of educating helm users about all the weird quirks they did not know Helm had. That is a scary proposition to me.
So, @powerful-elephant-53462 if you have specific concerns, I’m happy to address them — I do not want you to come away with the belief we’re not committed to making this work as well as we can. I just want to set expectations about why we are in the position we are today.
p
Understood, and thanks for the explanation.
undefined or surprising behavior is always bad 🙂
c
alright, with that in mind, do feel free to raise questions or concerns as you find them. If there are bugs we will definitely fix them quickly.
p
We’re on GKE, and most of our infrastructure is provisioned prior to the service-specific charts. The service-specific charts use naming conventions to find the right secrets/configmaps to find their credentials. So… maybe I’ll blissfully jump over the rough edges of helm integration? I’m about to find out 🙂
c
current default behavior is semantically equivalent to 
helm template
, btw
other than that, it’s probably what you’d expect
do let us know if you expect really robust tiller integraiton
in meetings… will be around soon
p
Nope, don’t need/want tiller. The fact that you’re running helm template is a good thing for us
c
sick.
o
👍
@creamy-potato-29402 this was really good context, and I realize it's not kosher for Pulumi to "bash" Helm publicly but I would have benefited from seeing the above in some form on the site
c
ha, yes, I have been reticent to just lay into them
o
@creamy-potato-29402 I've complained rather vocally about Helm charts being garbage (and the process for them broken), it would be absolutely amazing if people started shipping k8s components as NPM packages using Pulumi
c
I don’t want the team to feel attacked.
o
tbh they should feel attacked
c
I know a lot of people who work on it, and I want us to have a good relationship lol
o
the defaults of most helm charts are broken beyond use
c
Yes, that’s true.
o
the problem seems to be that 
stable/*
charts are not stable and not maintained by people who care about maintaining them, and the controls on the repository actively dissuade people interested in making fixes from doing so
end /rant
c
There are lots of other problems, too. Most of our complaints around helm are related to changing resources. Helm is surprisingly bad at upgrading, which is weird, because that’s its only job.
Because they don’t model lifecycle of objects at all, and because we do, it leads to a huge amount of pain when we are honest about what is going to happen to your resources
I don’t know why they call it a “Kubernetes package manager”, there is no such thing as a “kubernetes package manager”. There is only a distributed systems deployer, and THAT is a very complicated thing. You can’t just slap an 
upgrade
command on top and call it a day. You are setting your users up to fail.
p
Open in Slack
PreviousNext
Powered by