So, I agree, we should never need to use kill controller... but sometimes you might need it, like if someone SSH's into their controller and messes it up, etc.
Right now, kill-controller is in all the help docs, i.e. juju help commands... are we planning on changing that? I'm not sure I'm on board with having hidden commands, because they will invariably leak out, and then we just have commands that everyone knows about, but that are undocumented. I'd much prefer giant warning text: DANGER!!! USE THIS COMMAND ONLY AS A LAST RESORT!! IT MAY LEAVE RESOURCES RUNNING IN YOUR CLOUD! ALWAYS TRY destroy-controller FIRST! And make the flag to disable the "are you sure?" prompt something long and annoying to type, not just -y, because that's too easy to just bang out with muscle memory. In fact, if I were feeling sneaky, I might accept -y and still make them confirm, since they're obviously just banging out the command without thinking. -Nate On Wed, Apr 6, 2016 at 11:21 AM Rick Harding <rick.hard...@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. > > 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.jenni...@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.fi...@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.bent...@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@lists.ubuntu.com >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju-dev >>> >>> >> -- >> Juju-dev mailing list >> Juju-dev@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
