<div dir="ltr">I strongly feel that we're avoiding and dancing around the issue. <div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div><a href="https://bugs.launchpad.net/juju-core/+bug/1563615">https://bugs.launchpad.net/juju-core/+bug/1563615</a><br></div><div><br></div><div>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..."</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>Thanks</div><div><br></div><div>Rick</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Apr 6, 2016 at 11:02 AM Cheryl Jennings <<a href="mailto:cheryl.jennings@canonical.com">cheryl.jennings@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Another relevant bug:  <a href="https://bugs.launchpad.net/juju-core/+bug/1566426" target="_blank">https://bugs.launchpad.net/juju-core/+bug/1566426</a><div><br></div><div>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).</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 6, 2016 at 7:53 AM, Nate Finch <span dir="ltr"><<a href="mailto:nate.finch@canonical.com" target="_blank">nate.finch@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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).  <div><br></div><div>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).</div></div><div><div><br><div class="gmail_quote"><div dir="ltr">On Wed, Apr 6, 2016 at 10:48 AM Aaron Bentley <<a href="mailto:aaron.bentley@canonical.com" target="_blank">aaron.bentley@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br>
On 2016-04-06 10:45 AM, Nate Finch wrote:<br>
> Wait, didn't destroy-environment --force fall back to the provider?<br>
> I thought that was the whole point of --force<br>
<br>
No, it didn't fall back.  It uses the provider unconditionally,<br>
without trying a normal destroy-controller first.<br>
<br>
Aaron<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2<br>
<br>
iQEcBAEBCAAGBQJXBSG5AAoJEK84cMOcf+9hzSQIAJ/vNKIa1/TnDSyvC2U9ApzW<br>
TAEvSqaEUw0ZL2dl2tiNKTp3JPzcnCR4VKrBIsh1xi0hB1UNtJR+IW4O46gRI6ok<br>
ZvA1cAvoJvRdmqf1ntNzYwHRSn/Tm82DGzixTPt0TcTn3KYrk13XpRJuxMbbvHDM<br>
LfYG0zglGmVKUaWs4rBogh4H4OaiOIR8lORXSC8GRQjA1/C4c+FjIg+KeW5Yw2Ti<br>
XnG87BPyJ1TtPGWxxeKAk4tnkZwnZKtJOnHU/IfvTFOpECdBjojWnnc6VbQ1um0H<br>
WwjR6EcA4qxkkhND6ypIGkt9A4k3ZZvckCau52EgIn3pnwhk5OSw64MURJAEmn0=<br>
=vm/H<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div>
</div></div><br>--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
<br></blockquote></div><br></div>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</blockquote></div>