On Thu, Apr 7, 2016 at 12:40 PM John Meinel <[email protected]> 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" <[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
