How does Pulumi handle Kubernetes API deprecations...
# general
How does Pulumi handle Kubernetes API deprecations these days, e.g.: We have some
apiVersion: extensions/v1beta1
resources that we want to change to, e.g.
apiVersion: <|>
. My experience with Helm is that it kinda fucks up here, because for e.g.: a deployment named
, we can't tell Helm "don't change anything with this resource, just update Tiller with what the new API version is because k8s allows us to access a deployment via both extensions/v1beta1 and apps/v1". The result is we have to rename everything to
, experiencing some downtime because Helm will tear down the old deployment, stand up the new deployment, and often other stuff is also infected with the name via Helm templating so the service, the ingress, etc all get replaced and/or destroyed and recreated as the new name. Is there a way to make Pulumi just... accept that these resources are now
? That is, no update/replace/etc needed.
Pulumi aliases compatible Kubernetes API versions so that you should be able to upgrade from older to newer api versions. Are you seeing this not happen correctly in some case?
Nope, was just curious before I attempted to make the change.
Helm did the wrong thing here, so it's nice knowing there's another thing Pulumi might already be doing better
👍 1
@ambitious-intern-89629 is this the complete list of aliases that the k8s provider uses?
It looks like the list is here: I do suspect that list is not complete - if you see anything missing - please do open an issue. Also cc @gorgeous-egg-16927.
@white-balloon-205 @gorgeous-egg-16927:
Great - thanks!
Thanks for pulling that together. I did just fix a bug with the Ingress deprecation notice that hasn’t yet released, but you can test it out with the
tag. I’ll add entries for the other Kinds soon