-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Description
Is your feature request related to a problem? Please describe.
This is prompted by "#7608: az keyvault create silently zaps existing access policy when run on existing vault"
The crux of the problem is:
-
Some/most
createcommands are destructive and will silently do their destructive deed. -
There is no safety net.
-
This is not the default behaviour I want in production -- it's too scary.
-
Relying on humans not forget to check if resource already exists before
runningcreateis not the answer in the absence of safety net. -
With some
createcommands likeaz storage container createbeing
safe to run at any time, it makes it easier to forget that other commands
are not safe. -
Destructive commands are inconsistent and undocumented in what they destroy:
e.g.az keyvault createzaps access policies but leaves the secrets intact.
Practical test seems to be the only way to be 100% sure and it's a poor option. -
It is well within Azure CLI's capabilities to do the "remembering" and
safety net for us and thus provice a better experience here.
Describe the solution you'd like
The goal of the solution is:
- Make Azure CLI much safer to use;
- Bring consistency to the all commands;
- Do the "remembering" work for us humans;
- No nasty surprises.
The proposal is:
For all safe non-destructive create commands:
-
A safe
createcommand is a command which:- Safe to run at any time
- Never destroys or changes anything if target resource exists
- Actually creates target resource only if it does not exist
- Note that if we run
createwith parameters such that
it would lead to any chages in target resource it is not
a safe command. - Example:
az group create(it's safe, right?)
-
We can run it at any time just like now.
-
Consider for all such commands to have
--fail-on-existflag for
consistency (seeaz storage container create).
For all non-safe destructive create commands:
-
A non-safe
createcommand is any command which:- Destroys all or part of the target resource (see
az keyvault create) - Makes any changes to the target resource if it exists
- Some normally safe commands may become unsafe depending on paramteres.
- Destroys all or part of the target resource (see
-
Default behaviour for these should be:
- Command always fails if the target resource already exists.
- This reminds people to use
if resource exists; then update; else createpattern. - This provides much needed safety net.
-
For legacy and "I know what I'm doing" scenarios:
- Supply
--forceor similar flag. - This will enable to current destructive behaviour for
compatility/whatever other reasons.
- Supply
Describe alternatives you've considered
None really, open to suggestions which work towards the goals stated above.
Additional context
-
We have lots of people who use Azure CLI infrequently and in production.
It's very hard for them to remember what is safe and what isn't
and exact behaviour of each command, plus remembering to check for
resource existence when required. I include myself in this category. -
We have lots of automation and unattended deployments going on into all
environments, any human error in scripting Azure CLI is a potential disaster.
Making things safer would make things way way better.
EDIT1: corrected link to the issue which prompted this