Strong +1 to what Andrew just proposed<br><br>On Wednesday, 6 April 2016, Andrew Wilkins <<a href="mailto:andrew.wilkins@canonical.com">andrew.wilkins@canonical.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Apr 6, 2016 at 7:35 PM Rick Harding <<a href="javascript:_e(%7B%7D,'cvml','rick.harding@canonical.com');" target="_blank">rick.harding@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">+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. </div></blockquote><div><br></div><div>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.</div><div><br></div><div>I think the UX could do with rethinking. There's a few issues:</div><div> (1) It's too easy to lose resources via kill-controller. See: <a href="https://bugs.launchpad.net/juju-core/+bug/1559701" target="_blank">https://bugs.launchpad.net/juju-core/+bug/1559701</a> and <a href="https://bugs.launchpad.net/juju-core/+bug/1566011" target="_blank">https://bugs.launchpad.net/juju-core/+bug/1566011</a><br></div><div> (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.</div><div> (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.</div><div> <br></div><div>What I would like to see is:</div><div> * kill-controller to be dropped</div><div> * destroy-controller's --destroy-all-models flag to be dropped, and implied by the accepted prompt (or -y)</div><div> * 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</div><div> * a new command to remove a controller from the client</div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Andrew</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Apr 5, 2016 at 11:55 PM Andrew Wilkins <<a href="javascript:_e(%7B%7D,'cvml','andrew.wilkins@canonical.com');" target="_blank">andrew.wilkins@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings <<a href="javascript:_e(%7B%7D,'cvml','cheryl.jennings@canonical.com');" target="_blank">cheryl.jennings@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Relevant bug: <a href="https://bugs.launchpad.net/juju-core/+bug/1553059" target="_blank">https://bugs.launchpad.net/juju-core/+bug/1553059</a><div><br></div><div>We should provide a way to clean up controllers without making the user manually edit juju's files.</div></div></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Unless anyone objects, or has a better spelling, I will be adding a command to do this:</div><div><br></div><div> juju purge-controller <controller-name></div><div><br></div><div>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.</div><div><br></div><div>(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?)</div><div><br></div><div>Cheers,</div><div>Andrew</div></div></div><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','nate.finch@canonical.com');" target="_blank">nate.finch@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.</div><br><div class="gmail_quote"><div><div><div dir="ltr">On Mon, Apr 4, 2016 at 8:33 AM Rick Harding <<a href="javascript:_e(%7B%7D,'cvml','rick.harding@canonical.com');" target="_blank">rick.harding@canonical.com</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins <<a href="javascript:_e(%7B%7D,'cvml','andrew.wilkins@canonical.com');" target="_blank">andrew.wilkins@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">In a non-beta release we would make sure that the config changes aren't backwards incompatible.</div></div></div></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>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. </div></div></div></div></div><span>
--<br>
Juju-dev mailing list<br>
<a href="javascript:_e(%7B%7D,'cvml','Juju-dev@lists.ubuntu.com');" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</span></blockquote></div>
<br>--<br>
Juju-dev mailing list<br>
<a href="javascript:_e(%7B%7D,'cvml','Juju-dev@lists.ubuntu.com');" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div></blockquote></div></div></blockquote></div></div>
</blockquote>