[Issue] azd up should warn on potentially destructive changes when target resources exist and instead try to patch them #3512
Labels
aspire
core
customer-reported
identify a customer issue
enhancement
needs-team-attention
Issues out of a milestone
question
Milestone
Output from
azd version
Run
azd version
and copy and paste the output here:azd version 1.6.1 (commit eba2c97)
Describe the bug
azd up
is a great command. Following anazd init
, it just works - looks at what I've got, looks at where it's going and puts it there. Magical. But, also potentially disastrous. Today,azd
assumes it's the best source of truth for what the deployment should look like and I think that's right.. unless this isn't the first time anything has been deployed. The names of the resources it creates are idempotent and the resource group has already been identified.But let's say you run
azd up
to deploy a Container App and after it runs, you go in and configure an existing managed identity to bind to the Container App instance so it's got authority to communicate with other resources. If you were to runazd up
a second time, it'll destroy this Container App deployment (instead of just pushing a revision) and take with it this newly assigned UAI, meaning that your app will be deployed, but you'll have to go back and manually tweak it again.I can see this being quite frustrating if it doesn't just wipe out identity assignments, but also deletes certificates and secrets from deployed Key Vaults or obliterates export or monitoring configurations as I would expect that it wouldn't work this way. I would expect that it identifies that the target resource already exists, and it would deploy new resources for those that don't yet exist, but would download the existing templates, modify and patch those resources that are already there - in short perform a non-destructive upgrade.
And if this behavior isn't possible just yet, it should warn the user about what's going to happen and, absent a force flag, should have them sign off that the use of
azd up
instead ofazd deploy
is going to reset their deployed environment.To Reproduce
azd up
azd up
and when it completes, observe that your assignment in Restore some files we lost when migrating the repository #3 has silently become no more.Expected behavior
As I said before, I would expect that it would do a validation check before blindly deploying the resources. If a new resource exists locally, deploy it as it does today, but if target resources already exist, assume that Azure is the best source of truth for those resources, download their existing templates and patch those with the new deployment changes. And if a patch cannot be applied (e.g. it won't work because it's a virtual network or for some other foreseeable reason), require the developer to sign-off that they acknowledge this will be a destructive operation to any resources already deployed and that
azd deploy
might be a better option for what they're doing unless they've changed resources.Environment
Information on your environment:
C# 12
Visual Studio 17.10.0 Preview 1.0
Additional context
At some point I'm going to have to figure out where the line is between Aspire and azure-dev as I've once again been asked to file here after a brief back and forth here.
Thank you for the consideration!
The text was updated successfully, but these errors were encountered: