https://pulumi.com logo
Title
t

tall-scientist-89115

05/21/2021, 3:40 PM
Hey we noticed this morning our primary cluster was trying to swap out the vnet (and failing because it has resources), because someone on the team npm installed azure-native 1.7 and the (default) azure-native provider that created the resource was at 1.5. I guess locking versions would work.. but every time we upgrade azure-native we're going to have to rebuild the cluster? Did the arm interface change? I Was a bit surprised at this behavior from a minor release
b

billowy-army-68599

05/21/2021, 3:46 PM
can you share the diff?
l

limited-eve-38521

05/21/2021, 3:58 PM
specifically
[provider: urn:pulumi:prod-cluster::infra::pulumi:providers:azure-native::default_1_5_0::5472e0f4-f1bc-4d9f-8aa5-4818dd7b1307 => urn:pulumi:prod-cluster::infra::pulumi:providers:azure-native::default_1_7_0::3726aa65-bea9-4a3e-93ed-6c7fd82df168]
b

billowy-army-68599

05/21/2021, 4:01 PM
can you open an issue for this? that doesn't look right
l

limited-eve-38521

05/21/2021, 4:05 PM
will do
t

tall-librarian-49374

05/21/2021, 4:08 PM
Did you run a refresh before you got this diff?
l

limited-eve-38521

05/21/2021, 4:16 PM
ill try that
same diff after refresh
regarding the version change
t

tall-librarian-49374

05/21/2021, 4:26 PM
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
l

limited-eve-38521

05/21/2021, 4:31 PM
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
t

tall-scientist-89115

05/21/2021, 5:04 PM
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
I took it to the ticket