This message was deleted.

@tall-librarian-49374 Found you on the relevant discussion in GitHub. If you can, please shed some light on this, I'm literally stuck and have no idea what to do 🙂 🙏

For C# it still doesn't work, I resorted to using the previous version for that one resource. You can mix and match.

@worried-knife-31967 thank you so much! But which version are you referring to? Azure NextGen?

what's now referred to as "classic"

got it, thanks! it's actually pretty frustrating. I thought that Azure Native would be the way to go, but with issues like these... 😰

same same

Azure Native is modelled around ARM API. we present them 100% including all idiosyncrasies like subresourceid. or was there something Pulumi-specific? Please report as an issue if so.

https://www.pulumi.com/docs/reference/pkg/azure-native/network/frontdoor/ That's being presented as SubResourceArgs for the healthprobe. In TS, if I remember correctly, you can just override it and send more parameters, but not in C#.

@tall-librarian-49374 so, every parameter of FrontDoor presented as SubResourceArgs basically references subresources that should be created with the FrontDoor itself, they don't "live" without it. SubResourceArgs has only one property - Id which should be full resource Id as seen by Azure (as far as I understood). That means that before referencing these Ids we need already created "subresources" which are defined in the same FrontDoorArgs object. For example:

HealthProbeSettings = 
            {
                new AzureNative.Network.Inputs.HealthProbeSettingsModelArgs
                {
                    EnabledState = "Enabled",
                    HealthProbeMethod = "HEAD",
                    IntervalInSeconds = 120,
                    Name = "healthProbeSettings1",
                    Path = "/",
                    Protocol = "Http",
                },
            }

and apparently this settings should be referenced in BackendPoolArgs as:

HealthProbeSettings = new AzureNative.Network.Inputs.SubResourceArgs
                    {
                        Id = "/subscriptions/subid/resourceGroups/rg1/providers/Microsoft.Network/frontDoors/frontDoor1/healthProbeSettings/healthProbeSettings1",
                    },

I found no resource in Pulumi SDK which allows one to create HealthProbeSettings separately from FrontDoor. The same goes for:

LoadBalancingSettings 
FrontendEndpoints in RoutingRuleArgs
BackendPool in ForwardingConfigurationArgs

etc.

So what goes wrong in the example above? How is it different from ARM templates?

I'm not really familiar with ARM, but finally I think I got somewhere. So, it seems what you need to do is to construct the resource Id dynamically pretending that it has been already created at the definition time. Sigh... That's kinda strange, but guess this is how Azure works 🤦‍♂️ @worried-knife-31967

The Terraform resource doesn't do that, so I'm a) surprised that you have to do that in ARM, and b) that there's a reluctance to provide an example for an obscure setup like that.

@worried-knife-31967 that's true, I think Pulumi went ARM way to support 100% of the API and sync near real-time with changes in Azure which is a good thing. Some syntactic sugar for that would be great of course, but nothing actually prevents to implement your own. The bad thing is that we have to guess how it supposed to be used. Azure REST API isn't really helpful also. I am still trying to understand how to enable certificate provisioning for FrontDoor - banging my head against the wall again 😄

@freezing-memory-87554 customHttpsConfiguration seems to be missing from our API. let me check the details and come back to you.

much appreciated

that there’s a reluctance to provide an example for an obscure setup like that.

We do have one example https://www.pulumi.com/docs/reference/pkg/azure-native/network/frontdoor/ But again, we rely on ARM here and expose examples that Microsoft highlighted in their specs.

I guess I saw this issue, but it says "It does exist in others SDKs like Python, Go, .NET."...

Well, this is wrong

Got it, thanks! Azure Classic actually has this working, but I'm no expert in Pulumi internals to understand how exactly. It's still should be a POST request from the logical perspective. Will use Azure Classic for now. Much appreciate your help.

Yes, the classic provider calls the

EnableHTTPS

POST endpoint

By providing examples I mean a tested scenario where someone at pulumi has run it in to check that it works. Right now, as you've pointed out, only some of the resources YOUR api provides have been tested by yourselves. I get why, but you can't say that you've provided a working example when you have done it, and you're expecting the community to work it out. It's rant, I know, but I'm coming across more and more of these nuances with how you provided API works

Thank you for the feedback, it’s very useful