creamy-fall-88031
03/21/2022, 8:53 PMvnetSubnetId
. 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?little-cartoon-10569
03/21/2022, 9:09 PMcreamy-fall-88031
03/21/2022, 9:16 PMdependsOn
as a property of getSubnet
https://www.pulumi.com/registry/packages/azure-native/api-docs/network/getsubnet/?msclkid=0bd3191ca95c11ec88ee8240fb7cec0clittle-cartoon-10569
03/21/2022, 9:21 PMcreamy-fall-88031
03/21/2022, 9:40 PMconst 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?little-cartoon-10569
03/21/2022, 10:17 PMcreamy-fall-88031
03/21/2022, 10:29 PMvirtualNetwork
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?little-cartoon-10569
03/21/2022, 10:31 PMcreamy-fall-88031
03/21/2022, 10:35 PMconst 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
little-cartoon-10569
03/21/2022, 11:43 PMvirtualNetwork
, 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_nodejscreamy-fall-88031
03/21/2022, 11:51 PMSubnet.id
where I needed.little-cartoon-10569
03/21/2022, 11:52 PMsubnets
. I recommend creating resources separately and linking them, when that's possible.creamy-fall-88031
03/22/2022, 7:58 AMvirtualNetwork
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? πlittle-cartoon-10569
03/22/2022, 8:02 PMThe 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.