Unable to kill-controller

[John Meinel]

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.
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160407/8802ba1c/attachment-0001.html>