hey there! I’m curious, should auto-naming no longer be working as of version 3.0 of pulumi.azureAd? I opened an issue with details (https://github.com/pulumi/pulumi-azuread/issues/147) but the TLDR is that I can no longer create a

Group

without specifying either

Name

or

DisplayName

. This wasn’t the case with v 2.x

I am trying to figure out how to use a custom domain in front of azure nodejs functions, so that I can call them with https://stack.mydomain.com/api/foobar. I can not figure out how to do it. I cannot find any examples that does this in javascript.

It looks like the Azure NextGen provider has now been renamed to Azure Native, is this just a simple rename? Are we expecting GA soon? The fact that the readme states it is in private preview, yet the package is on nuget has confused me a bit

This isn't directly a Pulumi issue, but down to the terrible design of the Front Door API. There is a circular reference when trying to use the rules engine, where the rules engine depends on front door being created, but front door needs to reference the rules engine ID when it is created, any found a workaround for this? The MS workaround was to create the FD first, then run again to create the rules engine, which obviously won't work for a Pulumi project

hey there - anyone have any good examples on how to set up an AppGateway? My main hurdle now is the amount of

id:

references to objects being defined in the same configuration..

i.e., from https://www.pulumi.com/docs/reference/pkg/azure-native/network/applicationgateway/#create-application-gateway, a snippet from the httpListeners array:

httpListeners: [
        {
            frontendIPConfiguration: {
                id: "/subscriptions/subid/resourceGroups/rg1/providers/Microsoft.Network/applicationGateways/appgw/frontendIPConfigurations/appgwfip",
            },
            frontendPort: {
                id: "/subscriptions/subid/resourceGroups/rg1/providers/Microsoft.Network/applicationGateways/appgw/frontendPorts/appgwfp",
            },

would this not be a self reference of sorts, since the frontendIPConfiguration is made at the same time as the reference in httpListeners?

essentially, I just don't see -how- using pulumi I can fulfill those ids using anything other than strings - the exact thing I'm trying to avoid by using pulumi 😉

this is on azure-native (nextgen) btw. I noticed in good ol' azure it was easy to just make a reference to the name I specified in the higher level configuration - but having to supply the fully qualified ID is just beyond my understanding of how these things are supposed to work.

And blind as I am - I notice that i'm actually describing what @miniature-leather-70472 described above just one day ago, referencing yet another user with these circular references..

@better-shampoo-48884 Yeah, I ended up having to use the azure SDK to add the resource after creating the resource it depended on. Whoever at Microsoft designed those APIs needs talking to

Hi 👋🏻 Is it possible to retrieve the IP address of a deployed Function app? I can’t find it in either the classic or native Azure providers, and am in need of it for an

A

record for an apex domain custom hostname. The IP address is displayed in the Azure Portal next to the custom domain verification ID, but I can’t find it in the equivalent place in the provider APIs. Any ideas?

Hi, I'm having trouble finding an example of how to configure Azure Frontdoor using the new Azure.Native C# libraries. Do you have any examples you can point me to?

Finally!!! Honestly, the workaround for dealing with these self-references are a pain - but I'll show how I managed it below..

Updating (dev):
     Type                                        Name                 Status
     pulumi:pulumi:Stack                         iaac-experiment-dev
 +   └─ azure-native:network:ApplicationGateway  xxxxx-agw1-primary  created

So, for AppGW the httpListeners configuration and requestRoutingRules needs references to the frontendIPConfiguration, frontendPort, backendAddressPool, backendHttpSettings, and httpListener.. so yeah - requestRoutingRules defenition needs to reference the defenition of httpListener which needs to reference the defenition of frontendIPConfiguration and frontendPort... What I would like to see is this (as is with azure-classic):

frontendIpConfigurations: [{
  name: "frontendIp",
  ...
}],
frontendPorts: [{
  name: "frontendPort",
  ...
}],
httpListeners: [{
  name: "httpListenerDefault",
  frontendIPConfiguration: {
    // id: THIS IS INFURIATING
    name: frontendIp // <--- SO MUCH BETTER
  },
  frontendPort: { name: "frontendPort" }, // <--- so much nicer
}],
requestRoutingRules: [{
  name: "rule1",
  ...
  httpListener: {
    // id: AGAIN! so unnecessary
    name: "httpListenerDefault" // <-- so much more intuitive and easy to work with
  }
}]

Yes, the whole Network resource provider in Azure is designed around these ID references that are PITA

To make the "#¤" thing work in a semi-programatic fashion, after multiple trials and errors - we either need direct interpolation or to do the following (which worked for me):

frontendIPConfigurations: [{
            name: "appGwPublicFrontendIp",
            publicIPAddress: {
                id: pubIp.id
            }
        }],
        frontendPorts: appGw.frontendPorts,
        gatewayIPConfigurations: appGwIPC,
        httpListeners: [{
            frontendIPConfiguration: {
                id: rg.id.apply(id => `${id}/providers/Microsoft.Network/applicationGateways/${rgInfo.nodeName}${appGw.suffix}/frontendIPConfigurations/appGwPublicFrontendIp`),
            },
            frontendPort: {
                id: rg.id.apply(id => `${id}/providers/Microsoft.Network/applicationGateways/${rgInfo.nodeName}${appGw.suffix}/frontendPorts/frontendPortName`),
                
            },
            name: appGw.httpListeners[0].name,
            protocol: "Http",
        }],

(where

rg

is my resourceGroup defenition,

rgInfo.name + appGw.suffix

is the name of the appGw as defined on top)

I see no reason why pulumi cannot introduce a "name" field to the specification which performs this interpolation in the back - that way we can have a more clear and understandable configuration. At this point, I'm struggling to see the advantage of pulumi over arm templates in terms of logical flow and readability - which was fine in azure-classic.

afaik the restrictions on these references are that they must point to subresources within the same resource regardless - should it be possible to do otherwise, and someone actually have the need for it, the power of the

id

field is there - but there's a limit to the amount of self-flagellation that people would be willing to perform I believe.

How did you deal with the chicken-and-egg problem of two resources depending on each other and creation ordering problem? Or did you not need it?

did not need it - seems to be handled by internal ARM resolution

Oh, that’s something

requestRoutingRules depends on httpListeners which depend on frontendIPconfiguration and frontendPorts.. these were all declared simultaneously, with references - and they resolved nicely.

Do you mind opening an issue with your suggestion and a sample pseudocode? I don’t think we are tracking it.

my problem is having to hand-build the damned references when the fixed string concatenation for the id: field can be programatically derived by information pulumi already has available - yet there is not helper function.

ooh absolutely

issue on pulumi/pulumi or on the azure-native provider? makes more sense with the latter, right?

azure-native

https://github.com/pulumi/pulumi-azure-native/issues/631 that's as succinct as I feel I can put it

though looking at the appGw functionality, a programatic approach would be to autogenerate the dependencies of requestRoutingRules simply by defining them there (and then omitting httpListener config and the others). Granted, if I want to do that, I can do that, because, y'know, pulumi is written in actual programming languages 😄