so `VirtualMachine` implicitly creates reasources ...
# azure
h
so
VirtualMachine
implicitly creates reasources that pulumi doesn't track--disks and network interfaces and such. I noticed that the random ID logic isn't used with them. How are people working with this? Explicitly randomizing them? Explicitly tracking them as pulumi resources? just kinda shrugging?
m
I haven't created a VM in Azure yet with Pulumi so not sure this will work. Can you create those resources (disk, network interface, etc) with Pulumi and link them to the virtual machine?
h
That's what I mean by "explicitly tracking them"--rewriting the code so that they're pulumi resources instead of implied
but eg https://github.com/pulumi/templates/blob/master/vm-azure-python/__main__.py doesn't do that, just lets them be implied with non-randomized names
m
Sorry, I misunderstood. The documentation examples show some example of linking to existing resources. The first one shows linking to an existing network interface. I assume the other examples show everything else. I have a project coming up where I will be creating VMs and just assumed the code would have to explicitly create all resources. https://www.pulumi.com/registry/packages/azure-native/api-docs/compute/virtualmachine/
h
you're write, the example has an explicit network interface, so it doesn't run into the same problem
m
Sorry I don't have any example code. It looks like setting the OS disk can be linked to some other resource. It has the VHD property which I think is just the URI to the disk.
h
... yes, which is one of the solutions I mentioned in my original message.
I asked "what are best/common practices"
m
Oh, I'm so sorry. I really misunderstood your question.
Hah, I'll have to bow out then. I haven't made any VMs with Pulumi yet, so not sure how I or anyone would approach it. But I assume creating everything with Pulumi is the way to go
h
I do have one reason to explicitly manage disks through pulumi: You can only resize disks on the disk resource (not on the VM)