Thank you, Roger!
This sounds like an interesting use case :-)
At this stage, we can block commands not so much commands based on their
parameters . So, if you switch REMOVE_BLOCK on, any attempt to remove
services will be blocked regardless of the individual service :-)
However, blocking a particular entity from being manipulated sounds like
an interesting next stage. Maybe it should be recorded somewhere and
prioritized?
Sincerely Yours,
Anastasia
On 09/01/15 22:37, roger peppe wrote:
> This sounds great, thanks!
>
> Can you also block specific services from being removed?
> That would fit in well with my own usage, where there's a
> central database which would be a Bad Thing to remove,
> but the other services are much more ephemeral.
>
> cheers,
> rog.
>
> On 9 January 2015 at 06:52, Anastasia Macmood <
> anastasia.macm...@canonical.com> wrote:
>
>> I have recently worked on blocking juju commands. If you are creating
>> new commands, you may find this helpful :-)
>>
>> PROBLEM
>> Customers and stakeholders want to be able to prevent accidental damage
>> to their Juju deployments.
>>
>> SOLUTION
>> To prevent running some commands, we have introduced a concept of
>> command block. Once the block is switched on, it has to be manually
>> switched off to run commands successfully.
>>
>> There are currently three types of blocks developed.
>> DESTROY_BLOCK blocks destroy-environment command.
>> REMOVE_BLOCK blocks destroy-environment as well as all object removal -
>> machines, services, units, relations.
>> CHANGE_BLOCK blocks all commands from DESTROY and REMOVE blocks as well
>> as all environment modifications.
>> For more information and the list of all commands that are blocked, run
>> `juju help block` or `juju help unblock`.
>>
>> IMPLEMENTATION
>> These are the steps that I followed when blocking a command.
>>
>> A. Command (package cmd/juju)
>> 1. Help for block/unblock command is updated to contain your command.
>> 2. Delegate error processing of the client from apiserver error.
>> Most commonly, it would be done in the implementation of the Run from
>> Command interface.
>> E.g.
>>
>> func (c *SetFluffCommand) Run(_ *cmd.Context) (err error) {
>> ....
>> err := apiclient.SetFluff(args)
>> //there are corresponding block.BlockDestroy and block.BlockRemove
>> return block.ProcessBlockedError(err, block.BlockChange)
>> }
>>
>> 3. Add tests switching the block on before running the command.
>> Eg.
>>
>> // Block operation
>> s.AssertConfigParameterUpdated(c, "block-all-changes", true)
>>
>> B. Client (package apiserver)
>> 1. On desired operation, before any other processing, check if the block
>> is enabled using common.BlockChecker. Some client already have this checker
>> embedded. To construct new checker, you'll need a state.State.
>> E.g.
>>
>> func (c *Client) SetFluff(args params.SetFluff) error {
>> if err := c.check.ChangeAllowed(); err != nil {
>> return errors.Trace(err)
>> }
>> ......
>> }
>>
>> or
>>
>> func (c *Client) SetFluff(args params.SetFluff) error {
>> blockChecker := common.NewBlockChecker(st)
>> //there are corresponding blockChecker.DestroyAllowed() and
>> block.RemoveAllowed()
>> if err := blockChecker.ChangeAllowed(); err != nil {
>> return errors.Trace(err)
>> }
>> ......
>> }
>>
>> 2. Add tests switching the block on.
>>
>> C. Notify Interested Parties
>> At the very least, QA team might be interested in knowing that a new
>> command became blockable. Juju documentation may need to be updated as well
>> :)
>>
>> Let me know if this information is helpful.
>>
>> Sincerely Yours,
>>
>> Anastasia
>>
>>
>>
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
