Redeployment shouldn't remove manually assigned identities

[WhitWaldo]

I've got an existing Key Vault and managed user-assigned identity with the appropriate roles for accessing it. After deploying the container app via azd up, I assigned the UAI to it and everything worked as expected.

An hour later after I'd made a few more changes and re-deployed via azd up, I realized the app wasn't working. I dug into the logs and realized that as part of the redeployment, even though the other resources remained unchanged, the container app no longer listed my already-existing UAI (in addition to the one deployed by Aspire).

I sort of expected that re-deployments of container apps would kick off new revision deployments instead of deleting and deploying an entirely new container app, meaning that any changes I'd make to the app would persist, so please consider this a feature request - if I add my own identities to a deployed resource, updates to the deployment should start from whatever is already there and be additive for whatever it's trying to do rather than replace with a clean resource.

Thanks!

[davidfowl]

This is because you now have 2 sources of truth. Azd has no idea about the changes you manually made to the environment and using azd up (which does azd provision) will not keep those changes. There's currently no support for customizing the compute outside of generating the bicep using azd infra synth, this is still being worked on.

Changes to the environment outside of the app model or IaC will be overwritten when re-provisioning. azd is optimized for being able to repeatably create environments with infrastructure.

Running azd deploy will only deploy your compute and leave the infrastructure alone.

[WhitWaldo]

Typically, if you download an ARM template and re-apply it and nothing has changed, nothing happens. If you download the template and make a change to it, it only applies whatever has changed (except some of the older resources - looking at you vnets). And of course, if you deploy a brand new template, you get brand new resources.

But I guess I would expect some sort of guardrail up that prevents developers from inadvertently deploying a destructive template. The deployments appear to be idempotent - I might suggest adding a validation step: if there already exists a resource group matching the target deployment and it's filled with the same resource names as have been generated in the newly-prepared local template, throw on the brakes and have the developer confirm that they want to proceed with the operation (and accept a -F to force it through without the check).

Otherwise, I can easily see this being a source of great frustration that especially when the template supports references to existing resources, an inadvertent redeployment obliterating the roles on an existing Key Vault or dropping the relationship between an environment its App Insights instance because azd isn't aware of it.

[davidfowl]

Can you move this to https://github.com/Azure/azure-dev/issues?