rhythmic-finland-36256
09/13/2019, 3:56 PMServicePrincipal
authentication instead of the default CLI one. Now in one case the ServicePrincipal
I used had too few permissions to create `RoleAssignment`s. I now observe some inconsistencies between the pulumi state and what was created in the Azure subscription. Pulumi thinks everything but the `RoleAssignment`s has been created. With the corresponding permissions added to the ServicePrincipal
this now leads to the issue that the RoleAssignment
cannot be created as the desired ServicePrincipal
(not the login one) I want to assign the role doesn’t exist. This looks like a bug to me because Pulumi should not store resources (e.g. the ServicePrincipal
I wanted to create) if this was not successfully persisted at the provider level. Is there a way I can support debugging that case? I already did a pulumi refresh
which showed some resources as delete
but the case should be reproducible.AppRegistration
, ServicePrincipal
, ServicePrincipalPassword
, some other resource, here a ContainerRegistry
. Trying to create a RoleAssignment
for the ServicePrincipal results in an error, I was not able to find any resources on Azure, but the pulumi state had most of them listed.