Unable to kill-controller

[roger peppe]

My 2p:

FWIW I also would have no idea which was stronger, kill-controller
or destroy-controller. Assuming we do really want a separate command,
a variant of "destroy-controller" might be more intuitive, e.g.
"destroy-controller-with-prejudice", "destroy-controller-regardless"...

If fact I think this command will always need to remain around
and available to normal users, because people will always have
ways of managing instances behind Juju's back.
For example, people can terminate ec2 instances directly in the AWS console - it
might be inadvisable but it happens. The cloud is a complex
environment and things can fail (even if we write Juju perfectly)
in many ways.

My vote would be for a single command (destroy-controller)
which attempts to "do the right thing"
in all circumstances. Before attempting the shutdown and before
prompting the user for confirmation, it would try to connect to the API.
If it fails to connect to the API, the interactive confirmation prompt
would say something like "Cannot connect to controller. Do you want
to forcefully destroy all instances and other associated resources?",
different from the usual prompt.

With the --force flag, it would also try to connect to the controller
before destroying resources (same as kill-controller now).
With -y but without --force, it would not fall back to destroying
resources directly.

That way the confirmation message actually contains some useful info -
you get some feedback as to what's going on and we don't have
two subtly differently named commands.

  cheers,
    rog.

On 7 April 2016 at 05:54, Andrew Wilkins <andrew.wilkins at canonical.com> wrote:
> On Thu, Apr 7, 2016 at 12:40 PM John Meinel <john at arbash-meinel.com> wrote:
>>
>> Another aspect of this is actually that we made kill-controller "safe".
>> The fact that it does a "clean" shutdown first and then tries harder means I
>> have little motivation to use anything else. Also, for whatever reason I
>> find kill-controller easier to remember and type.
>>
>> Given Rick's fair position that having to kill I'd a sign of failure on
>> our part, what if:
>> 1. We stop being safe. People will be forced into a juju
>> destroy-controller || juju kill-controller position but that let's us
>> separate concerns.
>> 2. We move CI towards making kill-controller fail the test suite. If
>> destroy doesn't do everything they want, then we have a bug and it should be
>> telling developers that.
>
> SGTM. That will go further to discouraging kill-controller except when
> really necessary.
>>
>> 3. I personally like "forget-controller" over purge, and I don't like
>> "destroy, but don't actually destroy" type of forgetting.
>>
>> John
>> =:->
>>
>> On Apr 7, 2016 4:36 AM, "Rick Harding" <rick.harding at canonical.com> wrote:
>>>
>>>
>>>
>>> On Wed, Apr 6, 2016 at 8:25 PM Andrew Wilkins
>>> <andrew.wilkins at canonical.com> wrote:
>>>>
>>>> On Wed, Apr 6, 2016 at 11:28 PM Rick Harding
>>>> <rick.harding at canonical.com> wrote:
>>>>>
>>>>> I strongly feel that we're avoiding and dancing around the issue.
>>>>>
>>>>> The user should NEVER EVER have to use kill-controller. If someone
>>>>> types that we've failed to build Juju to the standards to which I feel we
>>>>> all should expect us to live up to. There is only ONE way for a user to take
>>>>> down a controller, destroy-controller.
>>>>
>>>>
>>>> I think it would be better if we hid kill-controller, but it's clear
>>>> from the bugs that people *are* using kill-controller and expecting it to be
>>>> more or less safe to use.
>>>
>>>
>>> But this comes back to what started this. People are using it because
>>> destroy-model isn't working for them. It's one part bug that it's not the
>>> reverse of bootstrap in its current form and one part that we've broken
>>> cleanup between betas so folks are looking for something that works. People
>>> are looking for it because they've got no choice.
>>>
>>>
>>>>
>>>> What about this scenario:
>>>> - Alice bootstraps, and adds user Bob with admin access.
>>>> - Bob registers the controller.
>>>> <time passes>
>>>> - The controller is still running and available, but Bob no longer needs
>>>> access to it.
>>>>
>>>> How does Bob remove the controller from his client without destroying
>>>> it? He's an admin, so "destroy-controller" will happily destroy everything.
>>>>
>>>> If we add a flag to destroy-controller to only clean up the cache, then
>>>> "oops, I forgot to add the flag" and now all the models are gone.
>>>>
>>>
>>> Agree that this is a mess. This is part that we don't have a way to give
>>> folks access without making them admins. I've got this towards the top of
>>> our 16.10 roadmap. I'd rather we did something temp with a plugin here or
>>> the like until we can get a real solution in place. This does bring up how
>>> this is going to work with other hosted model solutions.
>>>
>>>>>
>>>>> I don't feel that adding another command for another way to remove a
>>>>> controller from list-controllers is something we want to do and we
>>>>> especially don't want to do it this week as we try to freeze 2.0 for
>>>>> release.
>>>>>
>>>>> If folks think I'm missing a point please reach out to me and lets move
>>>>> this to a high-bandwidth discussion, but I wanted to share the original
>>>>> design/thought on the destroy vs kill controller commands. I want everyone
>>>>> to share the feeling that if our users ever type kill-controller into their
>>>>> terminals we've failed them and realize that.
>>>>
>>>>
>>>> If you like, we can leave it as-is for 2.0 -- no command to clean up the
>>>> cache -- and talk about it at the next sprint.
>>>
>>>
>>> I think that's best. I'd love to stop and figure this out right, but with
>>> everything breathing down our neck I fear we'll make a mistake we're stuck
>>> with until 3.0.
>>>
>>>
>>>
>>> --
>>> 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
>