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

specifically
```        [provider: urn:pulumi:prod-cluster::infra::pulumi:providers:azure-native::default_1_5_0::5472e0f4-f1bc-4d9f-8aa5-4818dd7b1307 =&gt; urn:pulumi:prod-cluster::infra::pulumi:providers:azure-native::default_1_7_0::3726aa65-bea9-4a3e-93ed-6c7fd82df168]```

can you open an issue for this? that doesn't look right

Sounds like <https://github.com/pulumi/pulumi-azure-native/issues/611>

Did you run a refresh before you got this diff?

I don’t think it’s related to the version. You’ll get it on refresh without a version update.

We haven’t changed the API version of the virtual network resource since 1.0  <https://github.com/pulumi/pulumi-azure-native/blame/master/sdk/dotnet/Network/VirtualNetwork.cs>

regarding the subnet issue i believe <https://github.com/pulumi/pulumi-azure-native/issues/611> is it

that happens whether we lock azure-native to 1.5 or not

~adding `{ ignoreChanges: ["subnets"] },` to the VirtualNetwork fixed it for us for now~

so if we rebuild this cluster, what's the best practice to avoiding this bug for now? Use the classic provider for the vn and az native for the subnets?

the other workaround mentioned in that ticket, `{ ignoreChanges: ['subnets'] }` , just resulted in the preview not showing the subnet replacement, but the update itself trying to create one