Strong +1 to what Andrew just proposed On Wednesday, 6 April 2016, Andrew Wilkins <andrew.wilk...@canonical.com> wrote:
> On Wed, Apr 6, 2016 at 7:35 PM Rick Harding <rick.hard...@canonical.com > <javascript:_e(%7B%7D,'cvml','rick.hard...@canonical.com');>> wrote: > >> +1 to the -1 of a new command for this. I'd like to raise the discussion >> with the technical board as I'd like understand why the change the change >> that the team had to make made it impossible for kill-controller to >> function and what we could do to allow the team to remove legacy code, but >> still be able to kill off things. >> > > Sorry, I probably should have started a new thread; this is orthogonal. > Still worth talking about with the board, but orthogonal to removing > details of a controller. You might "juju register" someone else's > controller, and then want to remove it from your client without destroying > it. > > I think the UX could do with rethinking. There's a few issues: > (1) It's too easy to lose resources via kill-controller. See: > https://bugs.launchpad.net/juju-core/+bug/1559701 and > https://bugs.launchpad.net/juju-core/+bug/1566011 > (2) It's not clear from the name what kill-controller vs. > destroy-controller is, and so it's easy to assume they either do the same > thing, or just randomly choose one and run it. That leads to (1) happening > more than we'd like or expect. > (3) destroy-controller is harder to use than kill-controller for the > standard case of destroying the controller and all of its hosted models. > You have to pass "--destroy-all-models" to destroy-controller, which you > don't have to pass to kill-controller. I don't understand the point of > that, given that you're already asked whether you want to destroy the > controller or not. > > What I would like to see is: > * kill-controller to be dropped > * destroy-controller's --destroy-all-models flag to be dropped, and > implied by the accepted prompt (or -y) > * destroy-controller to take on a --force flag, causing it to do what > kill-controller does now, and what destroy-environment --force used to do > * a new command to remove a controller from the client > > Why a new command? Because removing/forgetting is orthogonal to > destroying. It's plain weird to say "kill-controller --forget" (or > --cleanup, or whatever) if you're removing details of a live controller > that you just don't want to use any more. > > Cheers, > Andrew > > On Tue, Apr 5, 2016 at 11:55 PM Andrew Wilkins < >> andrew.wilk...@canonical.com >> <javascript:_e(%7B%7D,'cvml','andrew.wilk...@canonical.com');>> wrote: >> >>> On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings < >>> cheryl.jenni...@canonical.com >>> <javascript:_e(%7B%7D,'cvml','cheryl.jenni...@canonical.com');>> wrote: >>> >>>> Relevant bug: https://bugs.launchpad.net/juju-core/+bug/1553059 >>>> >>>> We should provide a way to clean up controllers without making the user >>>> manually edit juju's files. >>>> >>> >>> Unless anyone objects, or has a better spelling, I will be adding a >>> command to do this: >>> >>> juju purge-controller <controller-name> >>> >>> The command will require a "-y" or prompt for confirmation, like >>> kill-controller. It will not attempt to destroy the controller, it will >>> just remove the details of it from the client. >>> >>> (Alternative suggestion for spelling: "juju forget-controller". >>> Purge-controller may suggest that we're purging a controller of its >>> contents, rather than purging the controller from the client?) >>> >>> Cheers, >>> Andrew >>> >>> On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch <nate.fi...@canonical.com >>>> <javascript:_e(%7B%7D,'cvml','nate.fi...@canonical.com');>> wrote: >>>> >>>>> This just happened to me, too. Kill-controller needs to work if at >>>>> all possible. That's the whole point. And yes, users may not hit >>>>> specific >>>>> problems, but devs do, and that wastes our time trying to figure out how >>>>> to >>>>> manually clean up the garbage. >>>>> >>>>> On Mon, Apr 4, 2016 at 8:33 AM Rick Harding < >>>>> rick.hard...@canonical.com >>>>> <javascript:_e(%7B%7D,'cvml','rick.hard...@canonical.com');>> wrote: >>>>> >>>>>> On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins < >>>>>> andrew.wilk...@canonical.com >>>>>> <javascript:_e(%7B%7D,'cvml','andrew.wilk...@canonical.com');>> >>>>>> wrote: >>>>>> >>>>>>> In a non-beta release we would make sure that the config changes >>>>>>> aren't backwards incompatible. >>>>>>> >>>>>> >>>>>> I think this is the key thing. I think that kill-controller is an >>>>>> exception to this rule. I think we should always at least give the user >>>>>> the >>>>>> ability to remove their stuff and start over with the new alpha/beta/rc >>>>>> release. I'd like to ask us to explore making kill-controller an >>>>>> exception >>>>>> to this policy and that if tests prove we can't bootstrap on one beta and >>>>>> kill with trunk that it's a blocking bug for us. >>>>>> -- >>>>>> Juju-dev mailing list >>>>>> Juju-dev@lists.ubuntu.com >>>>>> <javascript:_e(%7B%7D,'cvml','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 >>>>> <javascript:_e(%7B%7D,'cvml','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
