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" <[email protected]> wrote: > > > On Wed, Apr 6, 2016 at 8:25 PM Andrew Wilkins < > [email protected]> wrote: > >> On Wed, Apr 6, 2016 at 11:28 PM Rick Harding <[email protected]> >> 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 > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
