Unable to kill-controller

[Nate Finch]

I agree with your assessment of the vocabulary, for what it's worth.

On Wed, Apr 6, 2016 at 9:41 AM Horacio Duran <horacio.duran at canonical.com>
wrote:

> 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>
>> wrote:
>>
>>> Strong +1 to what Andrew just proposed
>>>
>>> On Wednesday, 6 April 2016, Andrew Wilkins <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/936811a4/attachment.html>