Re: Unable to kill-controller

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2016-04-07 12:40 AM, John Meinel wrote: > 2. We move CI towards making kill-controller fail the test suite. > If destroy doesn't do everything they want, then we have a bug and > it should be telling developers that. e.g. exit status 0 = "I

Re: Unable to kill-controller

My 2p: FWIW I also would have no idea which was stronger, kill-controller or destroy-controller. Assuming we do really want a separate command, a variant of "destroy-controller" might be more intuitive, e.g. "destroy-controller-with-prejudice", "destroy-controller-regardless"... If fact I think

Re: Unable to kill-controller

On Thu, Apr 7, 2016 at 12:40 PM John Meinel wrote: > Another aspect of this is actually that we made kill-controller "safe". > The fact that it does a "clean" shutdown first and then tries harder means > I have little motivation to use anything else. Also, for whatever

Re: Unable to kill-controller

Another aspect of this is actually that we made kill-controller "safe". The fact that it does a "clean" shutdown first and then tries harder means I have little motivation to use anything else. Also, for whatever reason I find kill-controller easier to remember and type. Given Rick's fair

Re: Unable to kill-controller

On Thu, Apr 7, 2016 at 8:36 AM Rick Harding wrote: > On Wed, Apr 6, 2016 at 8:25 PM Andrew Wilkins < > andrew.wilk...@canonical.com> wrote: > >> On Wed, Apr 6, 2016 at 11:28 PM Rick Harding >> wrote: >> >>> I strongly feel that we're

Re: Unable to kill-controller

On Wed, Apr 6, 2016 at 8:25 PM Andrew Wilkins wrote: > On Wed, Apr 6, 2016 at 11:28 PM Rick Harding > wrote: > >> I strongly feel that we're avoiding and dancing around the issue. >> >> The user should NEVER EVER have to use

Re: Unable to kill-controller

On Wed, Apr 6, 2016 at 11:28 PM Rick Harding wrote: > I strongly feel that we're avoiding and dancing around the issue. > > The user should NEVER EVER have to use kill-controller. If someone types > that we've failed to build Juju to the standards to which I feel we

Re: Unable to kill-controller

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,

Re: Unable to kill-controller

On Thu, Apr 7, 2016 at 3:25 AM Aaron Bentley wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 2016-04-06 01:41 PM, Nate Finch wrote: > > I'd much prefer giant warning text: > > > > DANGER!!! USE THIS COMMAND ONLY AS A LAST RESORT!! IT MAY LEAVE > >

Re: Unable to kill-controller

On Thu, Apr 7, 2016 at 5:55 AM Alexis Bruemmer < alexis.bruem...@canonical.com> wrote: > Any reason why destroy-controller and kill-controller would not also > remove the local reference (purge-controller)? > Destroy/kill will always do that. The question is only whether we should have an

Re: Unable to kill-controller

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 wrote: > On 06/04/16 23:13, Nick Veitch wrote: > > Sure, I am just concerned about a proliferation of commands

Re: Unable to kill-controller

I obviously wasn't clear. I was suggesting a --yes-i-really-mean-it flag on kill-controller, but if you passed just -y we show the prompt anyway (instead of erroring out on an unknown flsg). My point with the big prompt was in response to Rick saying it should never be needed and should only be

Re: Unable to kill-controller

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

Re: Unable to kill-controller

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2016-04-06 01:41 PM, Nate Finch wrote: > I'd much prefer giant warning text: > > DANGER!!! USE THIS COMMAND ONLY AS A LAST RESORT!! IT MAY LEAVE > RESOURCES RUNNING IN YOUR CLOUD! ALWAYS TRY destroy-controller > FIRST! I don't see why this

Re: Unable to kill-controller

So, I agree, we should never need to use kill controller... but sometimes you might need it, like if someone SSH's into their controller and messes it up, etc. Right now, kill-controller is in all the help docs, i.e. juju help commands... are we planning on changing that? I'm not sure I'm on

Re: Unable to kill-controller

I strongly feel that we're avoiding and dancing around the issue. The user should NEVER EVER have to use kill-controller. If someone types that we've failed to build Juju to the standards to which I feel we all should expect us to live up to. There is only ONE way for a user to take down a

Re: Unable to kill-controller

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2016-04-06 11:02 AM, Cheryl Jennings wrote: > Another relevant bug: > https://bugs.launchpad.net/juju-core/+bug/1566426 > > Maybe kill-controller tries to destroy through the API, but has a > time out if things get "stuck" where it will fall

Re: Unable to kill-controller

Another relevant bug: https://bugs.launchpad.net/juju-core/+bug/1566426 Maybe kill-controller tries to destroy through the API, but has a time out if things get "stuck" where it will fall back to the provider. I was joking when I suggested yesterday in IRC that we should bring back --force for

Re: Unable to kill-controller

Oh I see. Yes, I agree that we should always try the right way first and only use the provider if necessary (especially if using the provider leaves garbage around). It seems like there's no reason why we couldn't make a --force flag do it that way in 2.0 (aside from time constraints). On Wed,

Re: Unable to kill-controller

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2016-04-06 10:45 AM, Nate Finch wrote: > Wait, didn't destroy-environment --force fall back to the provider? > I thought that was the whole point of --force No, it didn't fall back. It uses the provider unconditionally, without trying a normal

Re: Unable to kill-controller

Wait, didn't destroy-environment --force fall back to the provider? I thought that was the whole point of --force On Wed, Apr 6, 2016 at 10:24 AM Aaron Bentley wrote: > On 2016-04-06 08:22 AM, Andrew Wilkins wrote: > > What I would like to see is: *

Re: Unable to kill-controller

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2016-04-06 08:22 AM, Andrew Wilkins wrote: > What I would like to see is: * 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 What kill-controller

Re: Unable to kill-controller

I agree with your assessment of the vocabulary, for what it's worth. On Wed, Apr 6, 2016 at 9:41 AM Horacio Duran 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

Re: Unable to kill-controller

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 wrote: > Also +1 to

Re: Unable to kill-controller

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

Re: Unable to kill-controller

Strong +1 to what Andrew just proposed On Wednesday, 6 April 2016, Andrew Wilkins wrote: > On Wed, Apr 6, 2016 at 7:35 PM Rick Harding > wrote: > >> +1 to the -1 of a new

Re: Unable to kill-controller

On Wed, Apr 6, 2016 at 7:35 PM Rick Harding 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

Re: Unable to kill-controller

I agree with Horacio, forget controller is good becsude it only does what you expect, whereas failing to kill a controller but making it look like success is bad. Honestly, I think the problem is kill controller that should just go back to being a flag on destroy controller. Then we'd just have

Re: Unable to kill-controller

+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

Re: Unable to kill-controller

Sure, I am just concerned about a proliferation of commands to do the same (ultimately) task destroy-controller kill-controller forget/purge-controller On 6 April 2016 at 11:59, Horacio Duran wrote: > The issue I see with that approach is that in that case

Re: Unable to kill-controller

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,

Re: Unable to kill-controller

just my tuppence instead of having another command, can't we just add this as an option to kill-controller? juju kill-controller --cleanup On 6 April 2016 at 11:05, Horacio Duran wrote: > > I might be biased by years of apt-get but purge makes me think that you

Re: Unable to kill-controller

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 wrote: > On Tue, Apr 5, 2016 at 2:29 AM

Re: Unable to kill-controller

On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings < cheryl.jenni...@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

Re: Unable to kill-controller

On 05/04/16 11:12, Andrew Wilkins wrote: > On Mon, Apr 4, 2016 at 8:32 PM Rick Harding > wrote: > >> On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins < >> andrew.wilk...@canonical.com> wrote: >> >>> In a non-beta release we would make sure that the config changes

Re: Unable to kill-controller

On Mon, Apr 4, 2016 at 8:32 PM Rick Harding wrote: > On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins < > andrew.wilk...@canonical.com> wrote: > >> In a non-beta release we would make sure that the config changes aren't >> backwards incompatible. >> > > I think this is

Re: Unable to kill-controller

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. On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch wrote: > This just happened to me, too. Kill-controller

Re: Unable to kill-controller

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

Re: Unable to kill-controller

On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins 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

Re: Unable to kill-controller

On Sun, Apr 3, 2016 at 9:45 PM John Meinel wrote: > I'm not sure what happened, but I can't bootstrap, and I can't > kill-controller to try again. I started out with "failing to get > controller-uuid". I then manually killed the machines, but now I get > "unable to get

Re: Unable to kill-controller

I had exactly the same problem yesterday, but I put it down to having probably created the controller with beta2 and trying to kill it with beta3. I also resorted to the nuclear option in the end and deleted everything - I guess I could have been more circumspect and removed the particular parts

Unable to kill-controller

I'm not sure what happened, but I can't bootstrap, and I can't kill-controller to try again. I started out with "failing to get controller-uuid". I then manually killed the machines, but now I get "unable to get bootstrap information". Clearly there is *some* bootstrap information, or I would be