<div dir="ltr">Any reason why destroy-controller and kill-controller would not also remove the local reference (purge-controller)?</div><div class="gmail_extra"> <div class="gmail_quote">On Wed, Apr 6, 2016 at 1:54 PM, Tim Penhey <<a href="mailto:tim.penhey@canonical.com" target="_blank">tim.penhey@canonical.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 06/04/16 23:13, Nick Veitch wrote: > Sure, I am just concerned about a proliferation of commands to do the > same (ultimately) task > > destroy-controller The most correct way to take down a controller. > kill-controller The OMG it is broken, please do as much as you can and I know I'm going to have to manually check any resources left around that it couldn't clean up. > forget/purge-controller Remove local references to the controller. Not really the same things at all. Tim > > > > On 6 April 2016 at 11:59, Horacio Duran <<a href="mailto:horacio.duran@canonical.com">horacio.duran@canonical.com</a> > <mailto:<a href="mailto:horacio.duran@canonical.com">horacio.duran@canonical.com</a>>> wrote: > > The issue I see with that approach is that in that case > kill-controller might be doing less than you expect instead of more, > suppose the controller is having transient issues and kill > controller cannot reach the cloud for deletion, this would forget > the controller and leave it in the cloud, forget-controller instead > tells us very clearly what is going to happen, the change is going > to be local and not affect the controller. > My 2c > > > On Wednesday, 6 April 2016, Nick Veitch <<a href="mailto:nick.veitch@canonical.com">nick.veitch@canonical.com</a> <div class="HOEnZb"><div class="h5">> <mailto:<a href="mailto:nick.veitch@canonical.com">nick.veitch@canonical.com</a>>> wrote: > > just my tuppence > > instead of having another command, can't we just add this as an > option to kill-controller? > > juju kill-controller --cleanup <controller> > > > > On 6 April 2016 at 11:05, Horacio Duran > <<a href="mailto:horacio.duran@canonical.com">horacio.duran@canonical.com</a>> wrote: > > > I might be biased by years of apt-get but purge makes me > think that you are going to do what kill is supposed to do, > forget sound more aligned whit what you are really aiming to. > > On Wednesday, 6 April 2016, Andrew Wilkins > <<a href="mailto:andrew.wilkins@canonical.com">andrew.wilkins@canonical.com</a>> wrote: > > On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings > <<a href="mailto:cheryl.jennings@canonical.com">cheryl.jennings@canonical.com</a>> wrote: > > Relevant bug: > <a href="https://bugs.launchpad.net/juju-core/+bug/1553059" rel="noreferrer" target="_blank">https://bugs.launchpad.net/juju-core/+bug/1553059</a> > > 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 > <<a href="mailto:nate.finch@canonical.com">nate.finch@canonical.com</a>> 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 > <<a href="mailto:rick.harding@canonical.com">rick.harding@canonical.com</a>> wrote: > > On Sun, Apr 3, 2016 at 6:56 PM Andrew > Wilkins <<a href="mailto:andrew.wilkins@canonical.com">andrew.wilkins@canonical.com</a>> 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 > <a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a> > 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> > > > -- > Juju-dev mailing list > <a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a> > 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> > > > > -- > Juju-dev mailing list > <a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a> > 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> > > > > > -- > Nick Veitch, > CDO Documentation > Canonical > > > > > -- > Nick Veitch, > CDO Documentation > Canonical > > -- Juju-dev mailing list <a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a> 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> </div></div></blockquote></div> <div> </div>-- <div class="gmail_signature"><div dir="ltr">Alexis Bruemmer<div>Juju Core Manager, Canonical Ltd.</div><div>(503) 686-5018</div><div><a href="mailto:alexis.bruemmer@canonical.com" target="_blank">alexis.bruemmer@canonical.com</a></div></div></div> </div>