Restricting changes to running models

Deployed models can be protected from unintentional changes by disabling commands that can alter a model.

This is accomplished through the use of the disable-command command with one of three progressively restrictive command groups:

• destroy-model
• remove-object
• all

By disabling the destroy-model group, for instance, the user loses the ability to destroy both the model and its controller. Specifying the remove-object group adds to these restrictions by disabling the removal of machines, relations, applications and units. The all group disables the complete set of commands that can change the configuration of a model.

To give the user some feedback on why a command might be disabled, an optional message argument can be passed as part of the disable command.

For example, the following could be used to prevent execution of both the destroy-model and destroy-controller commands:

juju disable-command destroy-model "Check with SA before destruction."

If a user now attempts to destroy a protected model, they'd encounter an error similar to the following:

Destroying model
ERROR cannot destroy model: Check with SA before destruction.

destroy-model operation has been disabled for the current model.
To enable the command run

    juju enable-command destroy-model

Re-enabling a command

The reverse of disable-command is enable-command. This can be used with the corresponding group to restore a user's access to that group's commands:

juju enable-command destroy-model

By default, these actions are performed against the currently selected controller and model, but specific models can be targeted by using the additional '-m' or '--model' argument.

If you need to list which commands have been disabled, use disabled-commands:

juju disabled-commands

This will output will list any group that's currently disabled:

Disabled commands  Message
all

Commands within each enable and disable group