I agree with your assessment of the vocabulary, for what it's worth. On Wed, Apr 6, 2016 at 9:41 AM Horacio Duran <[email protected]> wrote:
> As a non English native myself I find destroy to be much more final than > kill, to me destroy sounds like kill and then burn just in case, but I > don't know if this extends to other non English speakers too. > > On Wednesday, 6 April 2016, Nate Finch <[email protected]> wrote: > >> Also +1 to Andrew's proposal. In particular, the difference between kill >> and destroy is pretty arbitrary from a vocabulary standpoint, so it's not >> clear which one is the default and which one is the extreme measure. A >> flag on destroy is a lot more clear in that regard (and reduces the number >> of commands needed). >> >> On Wed, Apr 6, 2016 at 8:41 AM Horacio Duran <[email protected]> >> wrote: >> >>> Strong +1 to what Andrew just proposed >>> >>> On Wednesday, 6 April 2016, Andrew Wilkins <[email protected]> >>> wrote: >>> >>>> On Wed, Apr 6, 2016 at 7:35 PM Rick Harding <[email protected]> >>>> 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 < >>>>> [email protected]> wrote: >>>>> >>>>>> On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings < >>>>>> [email protected]> 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 <[email protected]> >>>>>>> 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 < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins < >>>>>>>>> [email protected]> 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 >>>>>>>>> [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 >>>>>>>> >>>>>>>> >>>>>>>
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
