No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

I'd like this too, or better yet, an option to auto update resource types.

<https://github.com/pulumi/pulumi-kubernetes/pull/808/files>

set the `PULUMI_K8S_SUPPRESS_DEPRECATION_WARNINGS` flag

But, as they say, _caveat emptor_ :slightly_smiling_face:

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.

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.

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.

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.

Slightly OT, but how do you all transition workloads between EKS clusters?

Just curious since you’re actually pulumi users

Would it be safe enough to "clone" the provider using say `lodash` and then set `suppressDeprecationWarnings: true` for the helm templates?

you should be able to just set an env var in bash or windows

Yeah but say I want to only suppress for third party resources

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

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

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

Sounds like something Pulumi can help with; blue green cluster deployments anyone?

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/>