is there any way to disable the warnings from `@pu...
# general
b
is there any way to disable the warnings from
@pulumi/kubernetes
?
apps/v1beta1/Deployment is not supported by Kubernetes 1.16+ clusters. Use apps/v1/Deployment instead.
w
I'd like this too, or better yet, an option to auto update resource types.
c
set the
PULUMI_K8S_SUPPRESS_DEPRECATION_WARNINGS
flag
🙏 1
🍺 1
But, as they say, caveat emptor 🙂
I am super wary of auto-conversion for users, I have no idea what to be worried about there. If you have a clear idea I’d be happy to hear it.
w
You're right of course. Happy to be able to suppress for now, especially when they're coming from resources outside my control, like helm templates etc.
c
Just FYI, if you didn’t know: these resources are completely missing in 1.16+. If you are planning on moving there, you will simply not be able to use those charts
I think you have 9 months before 1.16 is the oldest supported version of Kubernetes.
w
Yeah, I think there are already PRs in progress for the prometheus operator helm charts.
I wish I could move to latest k8s, but aws eks lags by two releases.
☝️ 1
c
Classic EKS
w
Classic AWS 😢
c
Slightly OT, but how do you all transition workloads between EKS clusters?
Just curious since you’re actually pulumi users
w
Would it be safe enough to "clone" the provider using say
lodash
and then set
suppressDeprecationWarnings: true
for the helm templates?
c
you should be able to just set an env var in bash or windows
w
Yeah but say I want to only suppress for third party resources
c
Ah
I believe you need to instantiate actual providers each time—they’re an actual pulumi resource, and so they make RPC calls to the engine to register
so cloning it is probably going to get weird
w
Right, that's what I wondered.
We heading towards moving everything from ECS to EKS, emphasizing Kubernetes, so preferably reducing our explicit AWS dependencies.
So haven't had to think about cluster workloads much
c
A thing I’m perpetually interested in is that EKS doesn’t do in-place upgrades of the agents, which means you have to actually take all the stuff running in each cluster and move it to a different cluster when you upgrade
and since versions deprecate so fast, you have to do this pretty often
it seems like everyone has a special and slightly janky workflow for this
w
Sounds like something Pulumi can help with; blue green cluster deployments anyone?
w
This blog post is a key part of that - we’re thinking hard about what we can do to help automate this even more: https://www.pulumi.com/blog/day-2-kubernetes-migrating-eks-nodegroups-with-zero-downtime/