c

    creamy-fall-88031

    6 months ago
    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?
    l

    little-cartoon-10569

    6 months ago
    Add the dependsOn opt.
    c

    creamy-fall-88031

    6 months ago
    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
    l

    little-cartoon-10569

    6 months ago
    It's an opt. In the constructor, the 3rd parameter is opts. https://www.pulumi.com/docs/intro/concepts/resources/options/
    opts is very important; it's where you choose the provider, various lifecycle rules, aliases and dependency rules. It's worth going through that page, and some examples.
    c

    creamy-fall-88031

    6 months ago
    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?
    l

    little-cartoon-10569

    6 months ago
    Ah, I see, it's a getX, not a constructor, so yes, the 2nd argument.
    What is creating the subnet that you can't get? You probably need to get it from the associated object, rather than looking it up. Generally in Pulumi, getters are used quite rarely: only when you are referring to a well-known unmanaged resource. Which isn't the usual case.
    c

    creamy-fall-88031

    6 months ago
    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?
    l

    little-cartoon-10569

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

    creamy-fall-88031

    6 months ago
    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
    l

    little-cartoon-10569

    6 months ago
    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
    By referencing the subnetId this way, Pulumi knows that the VirtualNetworkRule is dependent on an output of the VirtualNetwork, so it won't try to create the rule until the network has finished being created.
    c

    creamy-fall-88031

    6 months ago
    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.
    Hey @little-cartoon-10569 thank you very much for all your help today!
    Much obliged
    l

    little-cartoon-10569

    6 months ago
    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.
    c

    creamy-fall-88031

    6 months ago
    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? πŸ™‚
    l

    little-cartoon-10569

    6 months ago
    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.