Unable to kill-controller

[Andrew Wilkins]

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