Is it possible to self reference a resource? I.e. ...
# generalt
tall-sandwich-14901
09/19/2022, 7:34 PMIs it possible to self reference a resource? I.e. say I wanted to use some of the info of an application registration in its creation, like so:
Copy code
const appReg = new azuread.Application("app", {
displayName: "name",
identifierUris: [`${baseUrl}/${self.applicationId}`]
})self.applicationIdl
little-cartoon-10569
09/19/2022, 8:04 PMNo. ApplicationID isn't know until after the resource is finished being created, but you're requiring it in order to create it. This cannot work.
t
tall-sandwich-14901
09/19/2022, 8:06 PM@little-cartoon-10569 would it be possible to create the resource and then modify its configuration in the same file?
tall-sandwich-14901
09/19/2022, 8:06 PMas a workaround
l
little-cartoon-10569
09/19/2022, 8:08 PMNo. Pulumi is declarative. Creating and editing aren't Pulumi concepts. Only "making a cloud resource be the same as this code resource".
little-cartoon-10569
09/19/2022, 8:08 PMYou cannot define one resource twice.
little-cartoon-10569
09/19/2022, 8:08 PMWhy do you want a variable URI?
little-cartoon-10569
09/19/2022, 8:09 PMWouldn't something like
${baseUrl}/namet
tall-sandwich-14901
09/19/2022, 9:02 PM@little-cartoon-10569 existing architecture issue
l
little-cartoon-10569
09/19/2022, 9:16 PMI think you'll have to do this in non-Pulumi code. Or els change your standards.
little-cartoon-10569
09/19/2022, 9:17 PMEven doing this through the console is a two-step process. Tell your team / architects that this is an anti-pattern than will cause issues later. And there's simply no need for it.
t
tall-sandwich-14901
09/19/2022, 9:35 PMI mean two step in then sense its multiple commands, but it is doable in one script which is nice.
Why would this url cause issues?
l
little-cartoon-10569
09/19/2022, 9:53 PMBecause the URI can't be created until after Azure has created the application. The ApplicationID can't be known in advance, so you can't set the value at creation time. You have to wait until creation has completed.
little-cartoon-10569
09/19/2022, 9:54 PMIf you destroy and recreate the application (which you might want to do at any time, and you will have to do at very awkward times like during disaster recovery), then you will have to update the URI, which means you will have to update anything that knows about that URI.
little-cartoon-10569
09/19/2022, 9:55 PMHaving a fixed URI for a logical application, instead of a variable URI for a specific application, is a far more robust option.
t
tall-sandwich-14901
09/19/2022, 10:21 PM@little-cartoon-10569 I see... Thank you for your help, I'll reach out to my team about it
👍 1
tall-sandwich-14901
09/20/2022, 6:48 PM@little-cartoon-10569 I've discussed it with my team. It seems that the configuration of the url with the variable id in it comes from this MS doc page (I have attached an image of the code I'm referring to on that page) - we are using the Azure Bot Service in our architecture. I have been testing without the usage of the bot-id in the url and I haven't found problems yet, but I was wondering if you might know more about this design choice from Microsoft. Note that the bot-id is identical to the app-id and is set by the application registration.
l
little-cartoon-10569
09/20/2022, 7:53 PMNope, sorry. Is there an explanation for why they use the ID? Maybe that's just the natural human inclination to overspecify with insufficient constraints? With just that picture, it's impossible to know if that config is "better" than, for example,
api://{Subdomain}.<http://example.com/{Azure|example.com/{Azure> AD AppName}little-cartoon-10569
09/20/2022, 7:55 PMMy guess is that that URI is overspecified, and it would have been better to put simply
api://{hostname}.{domain}/{pathToApp}{appUri}t
tall-sandwich-14901
09/20/2022, 8:26 PMNo unfortunately there is no explanation for their choice 😕
tall-sandwich-14901
09/20/2022, 8:27 PMBut those hunches and ideas seem reasonable