I am guessing that we have already covered the other side of destroying controllers....
1. If I am using someone else's controller and the admin of this controller destroys it, I get notified and I know I need to "purge" it.... 2. If I am an admin of the controller that other users are using, when I destroy it, I get notified that "other users are using this controller... are you sure you want to destroy it?"... On 07/04/16 07:54, Alexis Bruemmer wrote: > Any reason why destroy-controller and kill-controller would not also > remove the local reference (purge-controller)? > > On Wed, Apr 6, 2016 at 1:54 PM, Tim Penhey <[email protected] > <mailto:[email protected]>> wrote: > > 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 > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>> > 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 > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>> 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 > > <[email protected] > <mailto:[email protected]>> 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 > > <[email protected] > <mailto:[email protected]>> wrote: > > > > On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings > > <[email protected] > <mailto:[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] > <mailto:[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] > <mailto:[email protected]>> wrote: > > > > On Sun, Apr 3, 2016 at 6:56 PM Andrew > > Wilkins > <[email protected] > <mailto:[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] > <mailto:[email protected]> > > Modify settings or unsubscribe at: > > > https://lists.ubuntu.com/mailman/listinfo/juju-dev > > > > > > -- > > Juju-dev mailing list > > [email protected] > <mailto:[email protected]> > > Modify settings or unsubscribe at: > > > https://lists.ubuntu.com/mailman/listinfo/juju-dev > > > > > > > > -- > > Juju-dev mailing list > > [email protected] > <mailto:[email protected]> > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/juju-dev > > > > > > > > > > -- > > Nick Veitch, > > CDO Documentation > > Canonical > > > > > > > > > > -- > > Nick Veitch, > > CDO Documentation > > Canonical > > > > > > > -- > Juju-dev mailing list > [email protected] <mailto:[email protected]> > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > > > > > -- > Alexis Bruemmer > Juju Core Manager, Canonical Ltd. > (503) 686-5018 > [email protected] <mailto:[email protected]> > >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
