Unable to kill-controller
Anastasia Macmood
anastasia.macmood at canonical.com
Wed Apr 6 23:59:16 UTC 2016
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 <tim.penhey at canonical.com
> <mailto:tim.penhey at canonical.com>> 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
> <horacio.duran at canonical.com <mailto:horacio.duran at canonical.com>
> > <mailto:horacio.duran at canonical.com <mailto:horacio.duran at canonical.com>>>
> 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
> <nick.veitch at canonical.com <mailto:nick.veitch at canonical.com>
> > <mailto:nick.veitch at canonical.com
> <mailto:nick.veitch at canonical.com>>> 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
> > <horacio.duran at canonical.com
> <mailto:horacio.duran at canonical.com>> 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
> > <andrew.wilkins at canonical.com
> <mailto:andrew.wilkins at canonical.com>> wrote:
> >
> > On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings
> > <cheryl.jennings at canonical.com
> <mailto:cheryl.jennings at 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.finch at canonical.com
> <mailto:nate.finch at 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.harding at canonical.com
> <mailto:rick.harding at canonical.com>> wrote:
> >
> > On Sun, Apr 3, 2016 at 6:56 PM Andrew
> > Wilkins
> <andrew.wilkins at canonical.com
> <mailto:andrew.wilkins at 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 at lists.ubuntu.com
> <mailto:Juju-dev at lists.ubuntu.com>
> > Modify settings or unsubscribe at:
> >
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >
> >
> > --
> > Juju-dev mailing list
> > Juju-dev at lists.ubuntu.com
> <mailto:Juju-dev at lists.ubuntu.com>
> > Modify settings or unsubscribe at:
> >
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >
> >
> >
> > --
> > Juju-dev mailing list
> > Juju-dev at lists.ubuntu.com
> <mailto:Juju-dev at lists.ubuntu.com>
> > 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
> Juju-dev at lists.ubuntu.com <mailto:Juju-dev at lists.ubuntu.com>
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
>
>
> --
> Alexis Bruemmer
> Juju Core Manager, Canonical Ltd.
> (503) 686-5018
> alexis.bruemmer at canonical.com <mailto:alexis.bruemmer at canonical.com>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160407/49716e95/attachment.html>
More information about the Juju-dev
mailing list