https://pulumi.com logo
Powered by
Title
t

tall-sandwich-14901

09/19/2022, 7:34 PM
Is 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: 
const appReg = new azuread.Application("app", {
   displayName: "name",
   identifierUris: [`${baseUrl}/${self.applicationId}`]
})
Would something like 
self.applicationId
be possible?
l

little-cartoon-10569

09/19/2022, 8:04 PM
No. 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?
as a workaround
l

little-cartoon-10569

09/19/2022, 8:08 PM
No. Pulumi is declarative. Creating and editing aren't Pulumi concepts. Only "making a cloud resource be the same as this code resource".
You cannot define one resource twice.
Why do you want a variable URI?
Wouldn't something like 
${baseUrl}/name
be better, and more human-usable?
t

tall-sandwich-14901

09/19/2022, 9:02 PM
@little-cartoon-10569 existing architecture issue
l

little-cartoon-10569

09/19/2022, 9:16 PM
I think you'll have to do this in non-Pulumi code. Or els change your standards.
Even 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 PM
I 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 PM
Because 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.
If 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.
Having 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
@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 PM
Nope, 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}
.
My guess is that that URI is overspecified, and it would have been better to put simply 
api://{hostname}.{domain}/{pathToApp}
or even just 
{appUri}
.
t

tall-sandwich-14901

09/20/2022, 8:26 PM
No unfortunately there is no explanation for their choice 😕
But those hunches and ideas seem reasonable
#generalJoin Slack
Powered by