Hello. I've been testing the .net client over the last 24 hours to see if it's suitable to replace our ARM templates. It's going pretty well, but I have two questions: 1. How do people deal with the random AppService naming? The rest I get, but the name of the appservice also drives the URL it runs under, which has flow-on effects to stuff like custom domains, CORS policies, auth integration etc. Does every single person that uses Pulumi for app service deployment override the naming convention? 2. Currently we share a single resource group between our front-end and back-end arm templates, with the RG being created via the az command line if it doesn't exist already. How should this be represented within a Pulumi definition (considering we still want the stack definitions to remain separate between our front-end and back-end)?

Hi @adventurous-garage-59192 So you can use the Pulumi/random provider as part of your Pulumi scripts and it will take care of randomness When it comes to passing a stack name then I’d suggest a passing a resource group name via the CLi and Pulumi config Paul

Hi Paul, thanks for the response, but I'm unsure what you mean by using the random provider. I'm talking about the postfix added to the end of created resources, per https://github.com/pulumi/pulumi/issues/1518. Passing the RG name into the config does make sense, cheers.

@adventurous-garage-59192 you can set

Name

property of the app service to have an explicit fixed name

I'm aware I can set the name property, I'm just wondering if that's what people normally do considering this is the standard behavior. Having a postfix on regularly used Dev/Test/Prod AppService environments just seems like an unusable scenario. And yep, I assumed I would need to do something like that. Hardcoding the RG isn't a problem for the next few months.

Yeah, I understand what you mean. I can only refer you to https://www.pulumi.com/docs/intro/concepts/programming-model/#autonaming for now