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

Before:
```new kubernetes.apiextensions.CustomResource("test", {
  apiVersion: "<http://cloud.google.com/v1beta1|cloud.google.com/v1beta1>",
  kind: "BackendConfig",
  metadata: {
    name: "backendconfig",
    namespace: "test-namespace",
  },
  spec: {
    timeoutSec: 300,
  },
}, {})```
After (changing v1beta1 to v1 with alias option):
```new kubernetes.apiextensions.CustomResource("test", {
  apiVersion: "<http://cloud.google.com/v1|cloud.google.com/v1>",
  kind: "BackendConfig",
  metadata: {
    name: "backendconfig",
    namespace: "test-namespace",
  },
  spec: {
    timeoutSec: 300,
  },
}, {
  aliases: [{ type: "kubernetes:<http://cloud.google.com/v1beta1:BackendConfig|cloud.google.com/v1beta1:BackendConfig>" }],
})```
and I got
```        * the Kubernetes API server reported that "test-namespace/backendconfig" failed to fully initialize or become live: <http://BackendConfig.cloud.google.com|BackendConfig.cloud.google.com> "backendconfig" is invalid: apiVersion: Invalid value: "<http://cloud.google.com/v1|cloud.google.com/v1>": must be <http://cloud.google.com/v1beta1|cloud.google.com/v1beta1>```

From Kubernetes API log, looks Pulumi called PATCH API of `v1beta1` , and got rejected.
I use pulumi-kubernetes v2.9.1

Does changing the apiVersion field directly work?

Thanks for the response.
Yes. Changing apiVersion field with `kubectl` instead of Pulumi works.

Kubernetes API log told that `kubectl` called PATCH API of `v1`

Sorry, I meant changing the apiVersion here:

```new kubernetes.apiextensions.CustomResource("test", {
  apiVersion: "<http://cloud.google.com/v1|cloud.google.com/v1>",```

<@U0220CGL4P5> You meant without `aliases` option?

If I didn't specify `aliases` option, Pulumi tried to delete the `v1beta` resource and create the `v1` resource.

That would be my expectation - I don’t think changing resource version is a change you can do “in place” really, though I could be wrong.

I want to bump apiVersion in-place.
Kubernetes API supports this, as I succeeded with `kubectl`.

Also, Pulumi Kubernetes supports this for some built-in resources.
<https://github.com/pulumi/pulumi-kubernetes/pull/798>

I see - thanks for clarifying. Unfortunately, I don’t have anything useful to add :slightly_smiling_face:

This would be good to know as k8s 1.22 will require lots of these changes iirc

I am wondering why Pulumi Kubernetes calls `v1beta1` API instead of `v1` API even I specify `v1` manifest. Looks apiextentions.CustomResource honors previous API version in the state.