Unable to kill-controller

Wed Apr 6 13:41:24 UTC 2016

As a non English native myself I find destroy to be much more final than
kill, to me destroy sounds like kill and then burn just in case, but I
don't know if this extends to other non English speakers too.

On Wednesday, 6 April 2016, Nate Finch <nate.finch at canonical.com> wrote:

> Also +1 to Andrew's proposal.  In particular, the difference between kill
> and destroy is pretty arbitrary from a vocabulary standpoint, so it's not
> clear which one is the default and which one is the extreme measure.  A
> flag on destroy is a lot more clear in that regard (and reduces the number
> of commands needed).
>
> On Wed, Apr 6, 2016 at 8:41 AM Horacio Duran <horacio.duran at canonical.com
> <javascript:_e(%7B%7D,'cvml','horacio.duran at canonical.com');>> wrote:
>
>> Strong +1 to what Andrew just proposed
>>
>> On Wednesday, 6 April 2016, Andrew Wilkins <andrew.wilkins at canonical.com
>> <javascript:_e(%7B%7D,'cvml','andrew.wilkins at canonical.com');>> wrote:
>>
>>> On Wed, Apr 6, 2016 at 7:35 PM Rick Harding <rick.harding at canonical.com>
>>> wrote:
>>>
>>>> +1 to the -1 of a new command for this. I'd like to raise the
>>>> discussion with the technical board as I'd like understand why the change
>>>> the change that the team had to make made it impossible for kill-controller
>>>> to function and what we could do to allow the team to remove legacy code,
>>>> but still be able to kill off things.
>>>>
>>>
>>> Sorry, I probably should have started a new thread; this is orthogonal.
>>> Still worth talking about with the board, but orthogonal to removing
>>> details of a controller. You might "juju register" someone else's
>>> controller, and then want to remove it from your client without destroying
>>> it.
>>>
>>> I think the UX could do with rethinking. There's a few issues:
>>>  (1) It's too easy to lose resources via kill-controller. See:
>>> https://bugs.launchpad.net/juju-core/+bug/1559701 and
>>> https://bugs.launchpad.net/juju-core/+bug/1566011
>>>  (2) It's not clear from the name what kill-controller vs.
>>> destroy-controller is, and so it's easy to assume they either do the same
>>> thing, or just randomly choose one and run it. That leads to (1) happening
>>> more than we'd like or expect.
>>>  (3) destroy-controller is harder to use than kill-controller for the
>>> standard case of destroying the controller and all of its hosted models.
>>> You have to pass "--destroy-all-models" to destroy-controller, which you
>>> don't have to pass to kill-controller. I don't understand the point of
>>> that, given that you're already asked whether you want to destroy the
>>> controller or not.
>>>
>>> What I would like to see is:
>>>  * kill-controller to be dropped
>>>  * destroy-controller's --destroy-all-models flag to be dropped, and
>>> implied by the accepted prompt (or -y)
>>>  * destroy-controller to take on a --force flag, causing it to do what
>>> kill-controller does now, and what destroy-environment --force used to do
>>>  * a new command to remove a controller from the client
>>>
>>> Why a new command? Because removing/forgetting is orthogonal to
>>> destroying. It's plain weird to say "kill-controller --forget" (or
>>> --cleanup, or whatever) if you're removing details of a live controller
>>> that you just don't want to use any more.
>>>
>>> Cheers,
>>> Andrew
>>>
>>> On Tue, Apr 5, 2016 at 11:55 PM Andrew Wilkins <
>>>> andrew.wilkins at canonical.com> wrote:
>>>>
>>>>> On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings <
>>>>> cheryl.jennings at canonical.com> wrote:
>>>>>
>>>>>> Relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1553059
>>>>>>
>>>>>> We should provide a way to clean up controllers without making the
>>>>>> user manually edit juju's files.
>>>>>>
>>>>>
>>>>> Unless anyone objects, or has a better spelling, I will be adding a
>>>>> command to do this:
>>>>>
>>>>>     juju purge-controller <controller-name>
>>>>>
>>>>> The command will require a "-y" or prompt for confirmation, like
>>>>> kill-controller. It will not attempt to destroy the controller, it will
>>>>> just remove the details of it from the client.
>>>>>
>>>>> (Alternative suggestion for spelling: "juju forget-controller".
>>>>> Purge-controller may suggest that we're purging a controller of its
>>>>> contents, rather than purging the controller from the client?)
>>>>>
>>>>> Cheers,
>>>>> Andrew
>>>>>
>>>>> On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch <nate.finch at canonical.com>
>>>>>> wrote:
>>>>>>
>>>>>>> This just happened to me, too.  Kill-controller needs to work if at
>>>>>>> all possible.  That's the whole point.  And yes, users may not hit specific
>>>>>>> problems, but devs do, and that wastes our time trying to figure out how to
>>>>>>> manually clean up the garbage.
>>>>>>>
>>>>>>> On Mon, Apr 4, 2016 at 8:33 AM Rick Harding <
>>>>>>> rick.harding at canonical.com> wrote:
>>>>>>>
>>>>>>>> On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins <
>>>>>>>> andrew.wilkins at canonical.com> wrote:
>>>>>>>>
>>>>>>>>> In a non-beta release we would make sure that the config changes
>>>>>>>>> aren't backwards incompatible.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I think this is the key thing. I think that kill-controller is an
>>>>>>>> exception to this rule. I think we should always at least give the user the
>>>>>>>> ability to remove their stuff and start over with the new alpha/beta/rc
>>>>>>>> release. I'd like to ask us to explore making kill-controller an exception
>>>>>>>> to this policy and that if tests prove we can't bootstrap on one beta and
>>>>>>>> kill with trunk that it's a blocking bug for us.
>>>>>>>> --
>>>>>>>> Juju-dev mailing list
>>>>>>>> Juju-dev at lists.ubuntu.com
>>>>>>>> Modify settings or unsubscribe at:
>>>>>>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Juju-dev mailing list
>>>>>>> Juju-dev at lists.ubuntu.com
>>>>>>> Modify settings or unsubscribe at:
>>>>>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>>>>>
>>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160406/8cee34c3/attachment-0001.html>