Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Issue] azd up should warn on potentially destructive changes when target resources exist and instead try to patch them #3512

Open
1 task done
WhitWaldo opened this issue Mar 8, 2024 · 0 comments
Labels
Milestone

Comments

@WhitWaldo
Copy link

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 an azd 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 run azd 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 of azd deploy is going to reset their deployed environment.

To Reproduce

  1. Deploy a simple C# app via Aspire or the like that runs on an Azure Container App via azd up
  2. Create a separate user-assigned managed identity resource.
  3. Assign this resource to your container app identity.
  4. Re-run 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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants