Turns out I can't just add a fully qualified resource name string to

vnetSubnetId

. I need to invoke

getSubnet()

and then pass the resulting id. But now there is another error popping up. Pulumi complains on invoking

getSubnet()

on a virtual network resource which is still not being created. How can one overcome this issue?

Add the dependsOn opt.

Not sure what I'm doing wrong, but I don't see

dependsOn

as a property of

getSubnet

https://www.pulumi.com/registry/packages/azure-native/api-docs/network/getsubnet/?msclkid=0bd3191ca95c11ec88ee8240fb7cec0c

It's an opt. In the constructor, the 3rd parameter is opts. https://www.pulumi.com/docs/intro/concepts/resources/options/

Thanks for the help so far. But it seems that there are some things that I do not understand. This is my code snippet:

const postgreSubnet = azure.network.getSubnet({
    resourceGroupName: `rsg-cosmas-${pulumi.getStack()}-${randomNo}`,
    name: `snet-postgres-${pulumi.getStack()}-${randomNo}`,
    virtualNetworkName: `vnet-cosmas-${pulumi.getStack()}-${randomNo}`,

},
{
    dependsOn: [virtualNetwork]
});

here

opts

is the second argument (

pulumi.InvokeOptions

), but I am getting the following error

Argument of type '{ dependsOn: azure_native.network.VirtualNetwork[]; }' is not assignable to parameter of type 'InvokeOptions'.
Object literal may only specify known properties, and 'dependsOn' does not exist in type 'InvokeOptions'.

Is there another way to get a specific resource id (in this case subnet id) on resource creation? Something that won't require using

getSubnet()

or similar functions?

Ah, I see, it's a getX, not a constructor, so yes, the 2nd argument.

I'm creating 2 subnets via the

virtualNetwork

constructor from Azure native pulumi library, like so:

const virtualNetwork = new azure_native.network.VirtualNetwork(`vnet-cosmas-${pulumi.getStack()}-${randomNo}`, {
    addressSpace: {
        addressPrefixes: ["10.0.0.0/8"],
    },
    resourceGroupName: resourceGroup.name,
    subnets: [{
        addressPrefix: "10.0.2.0/24",
        name: `snet-postgres-${pulumi.getStack()}-${randomNo}`,
        serviceEndpoints: [{
            service: "Microsoft.Storage",
        }],
        delegations: [{
            name: "fs",
            serviceName: "Microsoft.DBforPostgreSQL/flexibleServers",
        }],
    },{
        addressPrefix: "10.0.1.0/24",
        name: `snet-aks-${pulumi.getStack()}-${randomNo}`,
    }],
    virtualNetworkName: `vnet-${pulumi.getStack()}-${randomNo}`,
});

I need the subnet ID's down the road to attach my vnet to both postgresql and aks cluster and I was only able to retrieve them via getSubnet(), but they need to be created so pulumi complains. Is there a way to get subnet id's as part of my previous code snippet, while/after the virtual network resource gets deployed?

Do they not come back in the subnets arg? You shouldn't have to look up anything.

well, since I'm very very new to both pulumi and typescript, I guess even if they do, I don't know how to reference them here. ☺️

const virtualNetworkRule = new azure_native.dbforpostgresql.VirtualNetworkRule(`vnetrule-cosmas-${pulumi.getStack()}-${randomNo}`, {
    ignoreMissingVnetServiceEndpoint: false,
    resourceGroupName: resourceGroup.name,
    serverName: `pg-cosmas-${pulumi.getStack()}-${randomNo}`,
    virtualNetworkRuleName: `vnetrule-cosmas-${pulumi.getStack()}-${randomNo}`,
    virtualNetworkSubnetId: pgSubnetId
},

last line:

virtualNetworkSubnetId: pgSubnetId

Assuming you've created an object

virtualNetwork

, I think it would be

virtualNetwork.subnets[0].id

. As per the docs: https://www.pulumi.com/registry/packages/azure-native/api-docs/network/virtualnetwork/#subnets_nodejs

That did not work and I ended up using the Subnet constructor separately. From there I was able to use

Subnet.id

where I needed.

When creating a VirtualNetwork, is it supposed to create subnets? If not, then this is the correct way to do it. Or you can configure the new subnet at the same time as creating the VirtualNetwork, via the

subnets

. I recommend creating resources separately and linking them, when that's possible.

AFAIK that's one of the differences between Azure Classic library and the Azure Native one. The second one is supposed to be fully compliant with the Azure API and therefore it's the recommended one. All the examples from the Pulumi docs show that one can create subnets via the

virtualNetwork

controller. That is the main reason why I've set my self on that path. If I were to create the infra via ARM templates as I am used to, I would've create separate VNET and SNET's and link them together, but we all love less code don't we? 🙂

A comment on this:

The second one is supposed to be fully compliant with the Azure API and therefore it's the recommended one.

Azure Native is built on Azure's APIs, which means occasionally it's closer to how you visualize things in the Azure console. But there's no particular reason as a user to recommend Native over Classic. Classic adds simple abstractions that are sometimes very useful. And since the IDs used by both Classic and Native are the Azure resource IDs, you can use both libraries together, when it's appropriate / useful. There is a reason for Pulumi to recommend Azure Native: it's pretty much automatically built and requires less maintenance from Pulumi than Classic does. So if Classic stops being used, Pulumi has more engineer-hours available to put into other work. But as a user, I think the two libraries should both be considered equal, and you should use whichever is better for your use case.