Unable to kill-controller

[Rick Harding]

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.

If a user has models running on that controller we've given them a flag to
safely say "I know I have stuff running, but I don't care" with the current
stuff running on there.

I completely understand that destroy-controller is not the reverse of
bootstrap. We've filed a bug for that and should correct the bug rather
than moving to other commands and processes to deal with that.

https://bugs.launchpad.net/juju-core/+bug/1563615

kill-controller is a top secret tool we keep in our back pockets for
emergency debugging when crap that's beyond our planning/control has
occurred and we've not yet updated destroy-controlller to be able to handle
that. It should not be in the main docs, release notes, etc. It's
dangerous, folks should be discouraged from ever using it. Even when we do
use it, we should be saying things like "Well, destroy-controller seems to
be broken, we've got this potentially messy/risky way of trying to work
around it that we can try...but..."

As for the user case where a user registers on someone else's controller
and wants to no longer have that controller appear, then we should update
destroy-controller to handle that. There's only ONE way to remove a
controller from your list, destroy-controller. We should be able to note
that the user requesting destroy-controller does not have sufficient access
to remove it and tell them "You've got these models running on this
controller". And if they want to destroy with the flag to remove all their
models, then we should do that and remove it from their system. If they
have no running models, we should note that we're removing that
controller's information from their system. If there's user confusion we
can look at a message "You are not the controller admin, removing the
controller information from your cache" or the like.

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.

Thanks

Rick

On Wed, Apr 6, 2016 at 11:02 AM Cheryl Jennings <
cheryl.jennings at canonical.com> wrote:

> Another relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1566426
>
> Maybe kill-controller tries to destroy through the API, but has a time out
> if things get "stuck" where it will fall back to the provider.  I was
> joking when I suggested yesterday in IRC that we should bring back --force
> for kill-controller, but maybe we need it (or at least a timeout).
>
> On Wed, Apr 6, 2016 at 7:53 AM, Nate Finch <nate.finch at canonical.com>
> wrote:
>
>> Oh I see.  Yes, I agree that we should always try the right way first and
>> only use the provider if necessary (especially if using the provider leaves
>> garbage around).
>>
>> It seems like there's no reason why we couldn't make a --force flag do it
>> that way in 2.0 (aside from time constraints).
>>
>> On Wed, Apr 6, 2016 at 10:48 AM Aaron Bentley <
>> aaron.bentley at canonical.com> wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>>
>>> On 2016-04-06 10:45 AM, Nate Finch wrote:
>>> > Wait, didn't destroy-environment --force fall back to the provider?
>>> > I thought that was the whole point of --force
>>>
>>> No, it didn't fall back.  It uses the provider unconditionally,
>>> without trying a normal destroy-controller first.
>>>
>>> Aaron
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v2
>>>
>>> iQEcBAEBCAAGBQJXBSG5AAoJEK84cMOcf+9hzSQIAJ/vNKIa1/TnDSyvC2U9ApzW
>>> TAEvSqaEUw0ZL2dl2tiNKTp3JPzcnCR4VKrBIsh1xi0hB1UNtJR+IW4O46gRI6ok
>>> ZvA1cAvoJvRdmqf1ntNzYwHRSn/Tm82DGzixTPt0TcTn3KYrk13XpRJuxMbbvHDM
>>> LfYG0zglGmVKUaWs4rBogh4H4OaiOIR8lORXSC8GRQjA1/C4c+FjIg+KeW5Yw2Ti
>>> XnG87BPyJ1TtPGWxxeKAk4tnkZwnZKtJOnHU/IfvTFOpECdBjojWnnc6VbQ1um0H
>>> WwjR6EcA4qxkkhND6ypIGkt9A4k3ZZvckCau52EgIn3pnwhk5OSw64MURJAEmn0=
>>> =vm/H
>>> -----END PGP SIGNATURE-----
>>>
>>
>> --
>> 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/0bf51fd5/attachment.html>