Re: New juju in ubuntu

On 7 April 2016 at 03:55, Marco Ceppi wrote: > > On Wed, Apr 6, 2016 at 10:07 AM Stuart Bishop > wrote: >> >> On 5 April 2016 at 23:35, Martin Packman >> wrote: >> >> > The challenge here is we want Juju 2.0

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: LXD v2.0.0-rc8 does not work with Juju v2.0-beta3

The rename works if you haven't removed `lxc1` which removes the original `lxcbr0`. If you have you will need to correctly configure another bridge as the new `lxcbr0` that is created has the same configuration as `lxdbr0` if you configured an `lxdbr0`... For me this led to two bridges with the

Re: LXD v2.0.0-rc8 does not work with Juju v2.0-beta3

I think you'll need to `service lxd-bridge restart' in either case. On 6 April 2016 at 22:18, Horacio Duran wrote: > yes, that workaround works, also you can change /etc/default/lxd-bridge > and restart the lxd-bridge service. > > On Wed, Apr 6, 2016 at 6:12 PM,

Re: LXD v2.0.0-rc8 does not work with Juju v2.0-beta3

yes, that workaround works, also you can change /etc/default/lxd-bridge and restart the lxd-bridge service. On Wed, Apr 6, 2016 at 6:12 PM, Casey Marshall wrote: > On Wed, Apr 6, 2016 at 2:51 PM, Alexis Bruemmer < > alexis.bruem...@canonical.com> wrote: > >> >> Hi

Re: LXD v2.0.0-rc8 does not work with Juju v2.0-beta3

On Wed, Apr 6, 2016 at 2:51 PM, Alexis Bruemmer < alexis.bruem...@canonical.com> wrote: > > Hi All, > > As recently highlighted in bug https://bugs.launchpad.net/bugs/1566589 the > latest LXD will not work with Juju 2.0-beta3. This is a result of LXD > moving to use a default bridge of lxdbr0

Re: New juju in ubuntu

On Wed, Apr 6, 2016 at 10:07 AM Stuart Bishop wrote: > On 5 April 2016 at 23:35, Martin Packman > wrote: > > > The challenge here is we want Juju 2.0 and all the new functionality > > to be the default on release, but not break our

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

LXD v2.0.0-rc8 does not work with Juju v2.0-beta3

Hi All, As recently highlighted in bug https://bugs.launchpad.net/bugs/1566589 the latest LXD will not work with Juju 2.0-beta3. This is a result of LXD moving to use a default bridge of lxdbr0 and Juju expecting lxcbr0. Thanks to the heads up and help from the LXD team there is a fix for this

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: New juju in ubuntu

On 5 April 2016 at 23:35, Martin Packman wrote: > The challenge here is we want Juju 2.0 and all the new functionality > to be the default on release, but not break our existing users who > have working Juju 1.X environments and no deployment upgrade path yet. > So,

Re: New juju in ubuntu

On Tue, Apr 5, 2016 at 1:37 PM Martin Packman wrote: > On 05/04/2016, Adam Collard wrote: > > Will there be a transitional release of 1.25.x that also gives us a juju1 > > binary to facilitate this? > > Yes, the plan entails both an

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