Description
openedon Oct 18, 2018
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
create
commands 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
runningcreate
is not the answer in the absence of safety net. -
With some
create
commands likeaz storage container create
being
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 create
zaps 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
create
command 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
create
with 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-exist
flag for
consistency (seeaz storage container create
).
For all non-safe destructive create
commands:
-
A non-safe
create
command 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 create
pattern. - This provides much needed safety net.
-
For legacy and "I know what I'm doing" scenarios:
- Supply
--force
or 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