This message was deleted.

Just one thought off the top of my head, note that I haven’t tested/validated any of this. 🙂 It wouldn’t surprise me for the subnets to be “parented” to the Vnet, which would change when you move to standalone. That change would lead to a resource replacement, which is not what you want. So, I’d get an export of the Pulumi state file and add

aliases

to the new standalone subnet resources to match the URNs as they were when nested in the Vnet. This should help avoid resource replacement, assuming you match all the other properties correctly.

ah yes, aliases, good call. Thanks. After reading a bit more on the subnet itself again (haven't touched our network in a long time) I'm now wondering if we should stick with inline defined. https://github.com/pulumi/pulumi-azure-native/issues/611 cc @happy-parrot-60128 Referencing values from the standalone resource in other resources is just easier than from the inline defined subnets.

You should be able to import subnets as standalone resources, then remove inline subnets from vnet entirely - and I'd hope this just magically works after our recent fixes

okay, so "standalone" subnets are now recommended? I know we used to have problems with them

They were very troublesome until https://github.com/pulumi/pulumi-azure-native/issues/611 got fixed - I think now they are first-class

okay, cool, that makes referencing them a lot easier and we don't have to do lookups within `vnet.subnets`by subnet name

Let us know if something doesn't work. It's relatively new - but we had a very large customer migrate and they sound happy since then.

Will do, thanks Mikhail. We're just slowly moving things over to azure-native at the moment and cleaning up our infracode