Skip to content

Feature/Discussion: provide safety net for create commands and make them consistent #7613

Open

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 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
    running create is not the answer in the absence of safety net.

  • With some create commands like az 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 (see az 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.
  • 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.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions