This message was deleted.
# azure
s
This message was deleted.
i
What kind of principal is this? I have an role assignment that I’ve set up and it works great with no issues
I did something like this and it worked well:
Copy code
PrincipalId = synw.Identity.Apply(v => { return v?.PrincipalId ?? ""; }),
d
It's a service principal used for an Azure DevOps Service Connection. I ended up creating a custom resource, that runs ... wait for it (close your eyes) a pulumi command that sleeps for 120 seconds. Just as a test. Then I subsequently started injecting this "stupid wait" as a dependency in the RoleAssignments.... honestly makes me want to barf, but I need this to be reliable.
i
im not 100% sure about Pulumi since im pretty new to the stack, but things like terraform usually build a dependency graph based on things properties that reference resources that should have been previously created. in theory if you’re referencing a PrincipalId for a resource that you’re managing via Pulumi, it should wait until that’s been completely created and then attempt to create the dependent resource.
d
Yep - that is true. I have been using that - but making use of the input/output automatic dependency functionality. E.g. I used Output<string> (the principal ID) as an input into the RoleAssignment - which should create that dependency. Even then, Azure sometimes fails. The failure is well documented though - its basically this from what I understand: a new AD group is created in a single region, then gets replicated. While replication is still taking place, the request to perform a RoleAssignment hits a different region which has not yet received the new AD group - boom. So, that's why I was chasing the terrible idea of injecting a silly time span into the whole thing - solely to hopefully allow this replication to occur.
i
interesting - ill keep an eye out for that as well. thanks for the heads up