Juju stable 1.25.5 is proposed for release

[Curtis Hovey-Canonical]

# juju-core 1.25.5

A new proposed stable release of Juju, juju-core 1.25.5, is now available.
This release may replace version 1.25.3 on Tuesday April 12.


## Getting Juju

juju-core 1.25.5 is available for Xenial and backported to earlier
series in the following PPA:

https://launchpad.net/~juju/+archive/proposed

Windows, Centos, and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.25.5

Proposed releases use the "proposed" simple-streams. You must configure
the `agent-stream` option in your environments.yaml to use the matching
juju agents.


## Notable Changes

This releases addresses stability and performance issues.


## Resolved issues

  * 1.25.4: units attempt to go through the proxy to download charm
from state server
Lp 1556207

  * Xenial juju 1.25.3 unable to deploy to lxc containers
Lp 1557345

  * Provider/maas bridge script is not idempotent
Lp 1553915

  * Unable to bootstrap lxd provider on s390x
Lp 1554675

  * Gce invalid volume id destroying environment
Lp 1556293

  * Juju_availability_zone not set in maas
Lp 1559099

  * Handle multi-series charms in 1.25
Lp 1563607

  * Apt-mirror is not used in containers with maas provider
Lp 1560391

  * Proxy updater fails with "permission denied"
Lp 1564694

  * Can-upgrade-to suggests a downgrade
Lp 1319890


Finally

We encourage everyone to subscribe the mailing list at
juju-...@lists.canonical.com, or join us on #juju-dev on freenode.


-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Juju stable 1.25.5 is proposed for release

[Curtis Hovey-Canonical]

# juju-core 1.25.5

A new proposed stable release of Juju, juju-core 1.25.5, is now available.
This release may replace version 1.25.3 on Tuesday April 12.


## Getting Juju

juju-core 1.25.5 is available for Xenial and backported to earlier
series in the following PPA:

https://launchpad.net/~juju/+archive/proposed

Windows, Centos, and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.25.5

Proposed releases use the "proposed" simple-streams. You must configure
the `agent-stream` option in your environments.yaml to use the matching
juju agents.


## Notable Changes

This releases addresses stability and performance issues.


## Resolved issues

  * 1.25.4: units attempt to go through the proxy to download charm
from state server
Lp 1556207

  * Xenial juju 1.25.3 unable to deploy to lxc containers
Lp 1557345

  * Provider/maas bridge script is not idempotent
Lp 1553915

  * Unable to bootstrap lxd provider on s390x
Lp 1554675

  * Gce invalid volume id destroying environment
Lp 1556293

  * Juju_availability_zone not set in maas
Lp 1559099

  * Handle multi-series charms in 1.25
Lp 1563607

  * Apt-mirror is not used in containers with maas provider
Lp 1560391

  * Proxy updater fails with "permission denied"
Lp 1564694

  * Can-upgrade-to suggests a downgrade
Lp 1319890


Finally

We encourage everyone to subscribe the mailing list at
juju-...@lists.canonical.com, or join us on #juju-dev on freenode.


-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

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

[Reed O'Brien]

np

On Thu, Apr 7, 2016 at 10:31 AM, roger peppe 
wrote:

> On 7 April 2016 at 17:34, Reed O'Brien  wrote:
> >> Do you want to NAT the IPv4 traffic? n
> >
> > You do want to NAT the traffic, unless you have routing explicitly setup.
>
> Ah, thanks. I knew it must be something stupid like that.
> It now bootstraps and works OK, yay! Thanks Reed.
>



-- 
Reed O'Brien
✉ reed.obr...@canonical.com
✆ 415-562-6797
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

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

[Reed O'Brien]

np

On Thu, Apr 7, 2016 at 10:31 AM, roger peppe 
wrote:

> On 7 April 2016 at 17:34, Reed O'Brien  wrote:
> >> Do you want to NAT the IPv4 traffic? n
> >
> > You do want to NAT the traffic, unless you have routing explicitly setup.
>
> Ah, thanks. I knew it must be something stupid like that.
> It now bootstraps and works OK, yay! Thanks Reed.
>



-- 
Reed O'Brien
✉ reed.obr...@canonical.com
✆ 415-562-6797
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

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

[roger peppe]

On 7 April 2016 at 17:34, Reed O'Brien  wrote:
>> Do you want to NAT the IPv4 traffic? n
>
> You do want to NAT the traffic, unless you have routing explicitly setup.

Ah, thanks. I knew it must be something stupid like that.
It now bootstraps and works OK, yay! Thanks Reed.

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

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

[roger peppe]

On 7 April 2016 at 17:34, Reed O'Brien  wrote:
>> Do you want to NAT the IPv4 traffic? n
>
> You do want to NAT the traffic, unless you have routing explicitly setup.

Ah, thanks. I knew it must be something stupid like that.
It now bootstraps and works OK, yay! Thanks Reed.

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

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

[Samuel Cozannet]

FYI, had the same issue on IBM hardware, and Antonio helped me get through
it:

* dpkg-reconfigure lxd was necessary to rename the bridge
* Then bootstrap still failed with
2016-04-07 16:35:17 ERROR cmd supercommand.go:448 no registered provider
for "lxd"
ERROR failed to bootstrap model: subprocess encountered error code 1

The fix for that was to add the --upload-tools tag in bootstrap.

So "juju bootstrap deeplearning lxd --upload-tools got me going.

Thanks!
Sam
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

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

[Reed O'Brien]

> Do you want to NAT the IPv4 traffic? n

You do want to NAT the traffic, unless you have routing explicitly setup.

On Thu, Apr 7, 2016 at 9:17 AM, roger peppe 
wrote:

> OK, thanks, that gets me further. I'd used the netmask from the
> example value in the default /etc/default/lxd-bridge - I assumed they were
> the same format, as the values were.
>
> ## IPv4 netmask (e.g. 255.255.255.0)
>
> Now my bootstrap is stuck further on while installing cpu-checker:
>
> http://paste.ubuntu.com/15673131/
>
> It's been like that for about an hour now. I should probably have
> bootstrapped
> with debug enabled, I guess. It may be a related issue if I mucked
> up the lxd bridge configuration somehow again.
>
>
> On 7 April 2016 at 16:25, Reed O'Brien  wrote:
> > I think you need to enter the CIDR netmask as a bit len, e.g. 24 rather
> than
> > as 255.255.255.0.
> >
> > See
> >
> https://github.com/reedobrien/juju-notes/blob/master/writing-a-ci-test.md
> > and the section on LXD for my personal notes about a working config.
> >
> > HTH,
> > Reed
> >
> > On Thu, Apr 7, 2016 at 8:14 AM, roger peppe 
> > wrote:
> >>
> >> I tried it. I get this error after typing in lots of ipv4 details:
> >>
> >> /var/lib/dpkg/info/lxd.postinst: 8: /var/lib/dpkg/info/lxd.postinst:
> >> arithmetic expression: expecting ')': " 5 - (255.255.255.0 / 8) "
> >>
> >> My full interaction was as follows: http://paste.ubuntu.com/15671384/
> >>
> >>
> >> On 7 April 2016 at 15:57, John Meinel  wrote:
> >> > Did you run dpkg-reconfigure lxd ? That's what I ran once I installed
> >> > the
> >> > new lxd package and it seemed to get things working. Tycho added some
> >> > helpful prompts as part of "juju bootstrap" to point users in the
> right
> >> > direction if LXD looks to be improperly configured.
> >> >
> >> > https://github.com/juju/juju/pull/4984
> >> >
> >> >
> >> > I'm trying to land that now.
> >> >
> >> > John
> >> > =:->
> >> >
> >> > On Apr 7, 2016 6:19 PM, "roger peppe" 
> wrote:
> >> >
> >> > To add to this conversation, I have encountered this issue today
> >> > and have been unable to resolve it so far in the limited time
> >> > I've been able to spend on it.
> >> >
> >> > I'm running on Trusty; I have the new version of lxd and the
> >> > latest version of Juju tip.
> >> >
> >> > In my case, the issue seems to be that my lcdbr0 interface
> >> > has no IPv4 addresses (I've tried fiddling with
> /etc/default/lxd-bridge
> >> > and restarting various things to avail) and that the
> >> > utils.GetAddressForInterface
> >> > function excludes all IPv4 addresses. I'm thinking that it shouldn't
> do
> >> > that,
> >> > but that might not be the only thing that's wrong.
> >> >
> >> >
> >> >
> >> > On 7 April 2016 at 05:10, Pete Vander Giessen 
> wrote:
> >> >> Hi All,
> >> >>
> >> >> Thank you very much for posting this thread. I've been following the
> >> >> "getting started" developer's guide at
> >> >> https://jujucharms.com/docs/devel/getting-started, and this info
> got me
> >> >> unstuck.
> >> >>
> >> >> I figured that I'd mention that, when I ran dpkg-reconfigure, I had
> to
> >> >> create an ipv4 subnet, rather than letting lxd use a proxy, as it
> does
> >> >> by
> >> >> default on a fresh install of Xenial. I'm not sure if it's
> necessarily
> >> >> related to the bridge issue, but I figured I'd be chatty about it in
> >> >> this
> >> >> thread, just in case it helps someone else get themselves unblocked,
> >> >> too
> >> >> (relevant debug logs posted below my sig).
> >> >>
> >> >> Thanks again,
> >> >>
> >> >> ~ PeteVG
> >> >>
> >> >> Logs from my install, before explicitly setting up the subnet:
> >> >>
> >> >> ~$ juju bootstrap --config default-series=xenial lxd-test lxd --debug
> >> >> 2016-04-07 03:51:01 INFO juju.cmd supercommand.go:60 running juju
> >> >> [2.0-beta3
> >> >> gc go1.6]
> >> >> 2016-04-07 03:51:01 INFO cmd cmd.go:141 cloud "lxd" not found, trying
> >> >> as a
> >> >> provider name
> >> >> 2016-04-07 03:51:01 INFO cmd cmd.go:141 no credentials found,
> checking
> >> >> environment
> >> >> 2016-04-07 03:51:01 DEBUG juju.cmd.juju.commands bootstrap.go:363
> >> >> preparing
> >> >> controller with config: map[default-series:xenial type:lxd name:admin
> >> >> uuid:9925cf81-618b-4d50-8f77-b16447c921d8
> >> >> controller-uuid:9925cf81-618b-4d50-8f77-b16447c921d8]
> >> >> 2016-04-07 03:51:01 ERROR cmd supercommand.go:448 invalid config: no
> >> >> addresses match
> >> >>
> >> >>
> >> >> On Wed, Apr 6, 2016 at 5:30 PM Reed O'Brien <
> reed.obr...@canonical.com>
> >> >> wrote:
> >> >>>
> >> >>> 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`
> >> 

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

[Reed O'Brien]

> Do you want to NAT the IPv4 traffic? n

You do want to NAT the traffic, unless you have routing explicitly setup.

On Thu, Apr 7, 2016 at 9:17 AM, roger peppe 
wrote:

> OK, thanks, that gets me further. I'd used the netmask from the
> example value in the default /etc/default/lxd-bridge - I assumed they were
> the same format, as the values were.
>
> ## IPv4 netmask (e.g. 255.255.255.0)
>
> Now my bootstrap is stuck further on while installing cpu-checker:
>
> http://paste.ubuntu.com/15673131/
>
> It's been like that for about an hour now. I should probably have
> bootstrapped
> with debug enabled, I guess. It may be a related issue if I mucked
> up the lxd bridge configuration somehow again.
>
>
> On 7 April 2016 at 16:25, Reed O'Brien  wrote:
> > I think you need to enter the CIDR netmask as a bit len, e.g. 24 rather
> than
> > as 255.255.255.0.
> >
> > See
> >
> https://github.com/reedobrien/juju-notes/blob/master/writing-a-ci-test.md
> > and the section on LXD for my personal notes about a working config.
> >
> > HTH,
> > Reed
> >
> > On Thu, Apr 7, 2016 at 8:14 AM, roger peppe 
> > wrote:
> >>
> >> I tried it. I get this error after typing in lots of ipv4 details:
> >>
> >> /var/lib/dpkg/info/lxd.postinst: 8: /var/lib/dpkg/info/lxd.postinst:
> >> arithmetic expression: expecting ')': " 5 - (255.255.255.0 / 8) "
> >>
> >> My full interaction was as follows: http://paste.ubuntu.com/15671384/
> >>
> >>
> >> On 7 April 2016 at 15:57, John Meinel  wrote:
> >> > Did you run dpkg-reconfigure lxd ? That's what I ran once I installed
> >> > the
> >> > new lxd package and it seemed to get things working. Tycho added some
> >> > helpful prompts as part of "juju bootstrap" to point users in the
> right
> >> > direction if LXD looks to be improperly configured.
> >> >
> >> > https://github.com/juju/juju/pull/4984
> >> >
> >> >
> >> > I'm trying to land that now.
> >> >
> >> > John
> >> > =:->
> >> >
> >> > On Apr 7, 2016 6:19 PM, "roger peppe" 
> wrote:
> >> >
> >> > To add to this conversation, I have encountered this issue today
> >> > and have been unable to resolve it so far in the limited time
> >> > I've been able to spend on it.
> >> >
> >> > I'm running on Trusty; I have the new version of lxd and the
> >> > latest version of Juju tip.
> >> >
> >> > In my case, the issue seems to be that my lcdbr0 interface
> >> > has no IPv4 addresses (I've tried fiddling with
> /etc/default/lxd-bridge
> >> > and restarting various things to avail) and that the
> >> > utils.GetAddressForInterface
> >> > function excludes all IPv4 addresses. I'm thinking that it shouldn't
> do
> >> > that,
> >> > but that might not be the only thing that's wrong.
> >> >
> >> >
> >> >
> >> > On 7 April 2016 at 05:10, Pete Vander Giessen 
> wrote:
> >> >> Hi All,
> >> >>
> >> >> Thank you very much for posting this thread. I've been following the
> >> >> "getting started" developer's guide at
> >> >> https://jujucharms.com/docs/devel/getting-started, and this info
> got me
> >> >> unstuck.
> >> >>
> >> >> I figured that I'd mention that, when I ran dpkg-reconfigure, I had
> to
> >> >> create an ipv4 subnet, rather than letting lxd use a proxy, as it
> does
> >> >> by
> >> >> default on a fresh install of Xenial. I'm not sure if it's
> necessarily
> >> >> related to the bridge issue, but I figured I'd be chatty about it in
> >> >> this
> >> >> thread, just in case it helps someone else get themselves unblocked,
> >> >> too
> >> >> (relevant debug logs posted below my sig).
> >> >>
> >> >> Thanks again,
> >> >>
> >> >> ~ PeteVG
> >> >>
> >> >> Logs from my install, before explicitly setting up the subnet:
> >> >>
> >> >> ~$ juju bootstrap --config default-series=xenial lxd-test lxd --debug
> >> >> 2016-04-07 03:51:01 INFO juju.cmd supercommand.go:60 running juju
> >> >> [2.0-beta3
> >> >> gc go1.6]
> >> >> 2016-04-07 03:51:01 INFO cmd cmd.go:141 cloud "lxd" not found, trying
> >> >> as a
> >> >> provider name
> >> >> 2016-04-07 03:51:01 INFO cmd cmd.go:141 no credentials found,
> checking
> >> >> environment
> >> >> 2016-04-07 03:51:01 DEBUG juju.cmd.juju.commands bootstrap.go:363
> >> >> preparing
> >> >> controller with config: map[default-series:xenial type:lxd name:admin
> >> >> uuid:9925cf81-618b-4d50-8f77-b16447c921d8
> >> >> controller-uuid:9925cf81-618b-4d50-8f77-b16447c921d8]
> >> >> 2016-04-07 03:51:01 ERROR cmd supercommand.go:448 invalid config: no
> >> >> addresses match
> >> >>
> >> >>
> >> >> On Wed, Apr 6, 2016 at 5:30 PM Reed O'Brien <
> reed.obr...@canonical.com>
> >> >> wrote:
> >> >>>
> >> >>> 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`
> >> 

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

[roger peppe]

OK, thanks, that gets me further. I'd used the netmask from the
example value in the default /etc/default/lxd-bridge - I assumed they were
the same format, as the values were.

## IPv4 netmask (e.g. 255.255.255.0)

Now my bootstrap is stuck further on while installing cpu-checker:

http://paste.ubuntu.com/15673131/

It's been like that for about an hour now. I should probably have bootstrapped
with debug enabled, I guess. It may be a related issue if I mucked
up the lxd bridge configuration somehow again.


On 7 April 2016 at 16:25, Reed O'Brien  wrote:
> I think you need to enter the CIDR netmask as a bit len, e.g. 24 rather than
> as 255.255.255.0.
>
> See
> https://github.com/reedobrien/juju-notes/blob/master/writing-a-ci-test.md
> and the section on LXD for my personal notes about a working config.
>
> HTH,
> Reed
>
> On Thu, Apr 7, 2016 at 8:14 AM, roger peppe 
> wrote:
>>
>> I tried it. I get this error after typing in lots of ipv4 details:
>>
>> /var/lib/dpkg/info/lxd.postinst: 8: /var/lib/dpkg/info/lxd.postinst:
>> arithmetic expression: expecting ')': " 5 - (255.255.255.0 / 8) "
>>
>> My full interaction was as follows: http://paste.ubuntu.com/15671384/
>>
>>
>> On 7 April 2016 at 15:57, John Meinel  wrote:
>> > Did you run dpkg-reconfigure lxd ? That's what I ran once I installed
>> > the
>> > new lxd package and it seemed to get things working. Tycho added some
>> > helpful prompts as part of "juju bootstrap" to point users in the right
>> > direction if LXD looks to be improperly configured.
>> >
>> > https://github.com/juju/juju/pull/4984
>> >
>> >
>> > I'm trying to land that now.
>> >
>> > John
>> > =:->
>> >
>> > On Apr 7, 2016 6:19 PM, "roger peppe"  wrote:
>> >
>> > To add to this conversation, I have encountered this issue today
>> > and have been unable to resolve it so far in the limited time
>> > I've been able to spend on it.
>> >
>> > I'm running on Trusty; I have the new version of lxd and the
>> > latest version of Juju tip.
>> >
>> > In my case, the issue seems to be that my lcdbr0 interface
>> > has no IPv4 addresses (I've tried fiddling with /etc/default/lxd-bridge
>> > and restarting various things to avail) and that the
>> > utils.GetAddressForInterface
>> > function excludes all IPv4 addresses. I'm thinking that it shouldn't do
>> > that,
>> > but that might not be the only thing that's wrong.
>> >
>> >
>> >
>> > On 7 April 2016 at 05:10, Pete Vander Giessen  wrote:
>> >> Hi All,
>> >>
>> >> Thank you very much for posting this thread. I've been following the
>> >> "getting started" developer's guide at
>> >> https://jujucharms.com/docs/devel/getting-started, and this info got me
>> >> unstuck.
>> >>
>> >> I figured that I'd mention that, when I ran dpkg-reconfigure, I had to
>> >> create an ipv4 subnet, rather than letting lxd use a proxy, as it does
>> >> by
>> >> default on a fresh install of Xenial. I'm not sure if it's necessarily
>> >> related to the bridge issue, but I figured I'd be chatty about it in
>> >> this
>> >> thread, just in case it helps someone else get themselves unblocked,
>> >> too
>> >> (relevant debug logs posted below my sig).
>> >>
>> >> Thanks again,
>> >>
>> >> ~ PeteVG
>> >>
>> >> Logs from my install, before explicitly setting up the subnet:
>> >>
>> >> ~$ juju bootstrap --config default-series=xenial lxd-test lxd --debug
>> >> 2016-04-07 03:51:01 INFO juju.cmd supercommand.go:60 running juju
>> >> [2.0-beta3
>> >> gc go1.6]
>> >> 2016-04-07 03:51:01 INFO cmd cmd.go:141 cloud "lxd" not found, trying
>> >> as a
>> >> provider name
>> >> 2016-04-07 03:51:01 INFO cmd cmd.go:141 no credentials found, checking
>> >> environment
>> >> 2016-04-07 03:51:01 DEBUG juju.cmd.juju.commands bootstrap.go:363
>> >> preparing
>> >> controller with config: map[default-series:xenial type:lxd name:admin
>> >> uuid:9925cf81-618b-4d50-8f77-b16447c921d8
>> >> controller-uuid:9925cf81-618b-4d50-8f77-b16447c921d8]
>> >> 2016-04-07 03:51:01 ERROR cmd supercommand.go:448 invalid config: no
>> >> addresses match
>> >>
>> >>
>> >> On Wed, Apr 6, 2016 at 5:30 PM Reed O'Brien 
>> >> wrote:
>> >>>
>> >>> 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
>> >>> same
>> >>> address info, which didn't work out so slick.
>> >>>
>> >>> Also, you need to `systemctl stop lxd-bridge.service && systemctl
>> >>> restart
>> >>> lxd.service` in the correct order.
>> >>>
>> >>> On Wed, Apr 6, 2016 at 2:22 PM, Andrew McDermott
>> >>>  wrote:
>> 
>>  I think you'll need to `service lxd-bridge restart' in 

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

[roger peppe]

OK, thanks, that gets me further. I'd used the netmask from the
example value in the default /etc/default/lxd-bridge - I assumed they were
the same format, as the values were.

## IPv4 netmask (e.g. 255.255.255.0)

Now my bootstrap is stuck further on while installing cpu-checker:

http://paste.ubuntu.com/15673131/

It's been like that for about an hour now. I should probably have bootstrapped
with debug enabled, I guess. It may be a related issue if I mucked
up the lxd bridge configuration somehow again.


On 7 April 2016 at 16:25, Reed O'Brien  wrote:
> I think you need to enter the CIDR netmask as a bit len, e.g. 24 rather than
> as 255.255.255.0.
>
> See
> https://github.com/reedobrien/juju-notes/blob/master/writing-a-ci-test.md
> and the section on LXD for my personal notes about a working config.
>
> HTH,
> Reed
>
> On Thu, Apr 7, 2016 at 8:14 AM, roger peppe 
> wrote:
>>
>> I tried it. I get this error after typing in lots of ipv4 details:
>>
>> /var/lib/dpkg/info/lxd.postinst: 8: /var/lib/dpkg/info/lxd.postinst:
>> arithmetic expression: expecting ')': " 5 - (255.255.255.0 / 8) "
>>
>> My full interaction was as follows: http://paste.ubuntu.com/15671384/
>>
>>
>> On 7 April 2016 at 15:57, John Meinel  wrote:
>> > Did you run dpkg-reconfigure lxd ? That's what I ran once I installed
>> > the
>> > new lxd package and it seemed to get things working. Tycho added some
>> > helpful prompts as part of "juju bootstrap" to point users in the right
>> > direction if LXD looks to be improperly configured.
>> >
>> > https://github.com/juju/juju/pull/4984
>> >
>> >
>> > I'm trying to land that now.
>> >
>> > John
>> > =:->
>> >
>> > On Apr 7, 2016 6:19 PM, "roger peppe"  wrote:
>> >
>> > To add to this conversation, I have encountered this issue today
>> > and have been unable to resolve it so far in the limited time
>> > I've been able to spend on it.
>> >
>> > I'm running on Trusty; I have the new version of lxd and the
>> > latest version of Juju tip.
>> >
>> > In my case, the issue seems to be that my lcdbr0 interface
>> > has no IPv4 addresses (I've tried fiddling with /etc/default/lxd-bridge
>> > and restarting various things to avail) and that the
>> > utils.GetAddressForInterface
>> > function excludes all IPv4 addresses. I'm thinking that it shouldn't do
>> > that,
>> > but that might not be the only thing that's wrong.
>> >
>> >
>> >
>> > On 7 April 2016 at 05:10, Pete Vander Giessen  wrote:
>> >> Hi All,
>> >>
>> >> Thank you very much for posting this thread. I've been following the
>> >> "getting started" developer's guide at
>> >> https://jujucharms.com/docs/devel/getting-started, and this info got me
>> >> unstuck.
>> >>
>> >> I figured that I'd mention that, when I ran dpkg-reconfigure, I had to
>> >> create an ipv4 subnet, rather than letting lxd use a proxy, as it does
>> >> by
>> >> default on a fresh install of Xenial. I'm not sure if it's necessarily
>> >> related to the bridge issue, but I figured I'd be chatty about it in
>> >> this
>> >> thread, just in case it helps someone else get themselves unblocked,
>> >> too
>> >> (relevant debug logs posted below my sig).
>> >>
>> >> Thanks again,
>> >>
>> >> ~ PeteVG
>> >>
>> >> Logs from my install, before explicitly setting up the subnet:
>> >>
>> >> ~$ juju bootstrap --config default-series=xenial lxd-test lxd --debug
>> >> 2016-04-07 03:51:01 INFO juju.cmd supercommand.go:60 running juju
>> >> [2.0-beta3
>> >> gc go1.6]
>> >> 2016-04-07 03:51:01 INFO cmd cmd.go:141 cloud "lxd" not found, trying
>> >> as a
>> >> provider name
>> >> 2016-04-07 03:51:01 INFO cmd cmd.go:141 no credentials found, checking
>> >> environment
>> >> 2016-04-07 03:51:01 DEBUG juju.cmd.juju.commands bootstrap.go:363
>> >> preparing
>> >> controller with config: map[default-series:xenial type:lxd name:admin
>> >> uuid:9925cf81-618b-4d50-8f77-b16447c921d8
>> >> controller-uuid:9925cf81-618b-4d50-8f77-b16447c921d8]
>> >> 2016-04-07 03:51:01 ERROR cmd supercommand.go:448 invalid config: no
>> >> addresses match
>> >>
>> >>
>> >> On Wed, Apr 6, 2016 at 5:30 PM Reed O'Brien 
>> >> wrote:
>> >>>
>> >>> 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
>> >>> same
>> >>> address info, which didn't work out so slick.
>> >>>
>> >>> Also, you need to `systemctl stop lxd-bridge.service && systemctl
>> >>> restart
>> >>> lxd.service` in the correct order.
>> >>>
>> >>> On Wed, Apr 6, 2016 at 2:22 PM, Andrew McDermott
>> >>>  wrote:
>> 
>>  I think you'll need to `service lxd-bridge restart' in 

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

[Reed O'Brien]

I think you need to enter the CIDR netmask as a bit len, e.g. 24 rather
than as 255.255.255.0.

See
https://github.com/reedobrien/juju-notes/blob/master/writing-a-ci-test.md
and the section on LXD for my personal notes about a working config.

HTH,
Reed

On Thu, Apr 7, 2016 at 8:14 AM, roger peppe 
wrote:

> I tried it. I get this error after typing in lots of ipv4 details:
>
> /var/lib/dpkg/info/lxd.postinst: 8: /var/lib/dpkg/info/lxd.postinst:
> arithmetic expression: expecting ')': " 5 - (255.255.255.0 / 8) "
>
> My full interaction was as follows: http://paste.ubuntu.com/15671384/
>
>
> On 7 April 2016 at 15:57, John Meinel  wrote:
> > Did you run dpkg-reconfigure lxd ? That's what I ran once I installed the
> > new lxd package and it seemed to get things working. Tycho added some
> > helpful prompts as part of "juju bootstrap" to point users in the right
> > direction if LXD looks to be improperly configured.
> >
> > https://github.com/juju/juju/pull/4984
> >
> >
> > I'm trying to land that now.
> >
> > John
> > =:->
> >
> > On Apr 7, 2016 6:19 PM, "roger peppe"  wrote:
> >
> > To add to this conversation, I have encountered this issue today
> > and have been unable to resolve it so far in the limited time
> > I've been able to spend on it.
> >
> > I'm running on Trusty; I have the new version of lxd and the
> > latest version of Juju tip.
> >
> > In my case, the issue seems to be that my lcdbr0 interface
> > has no IPv4 addresses (I've tried fiddling with /etc/default/lxd-bridge
> > and restarting various things to avail) and that the
> > utils.GetAddressForInterface
> > function excludes all IPv4 addresses. I'm thinking that it shouldn't do
> > that,
> > but that might not be the only thing that's wrong.
> >
> >
> >
> > On 7 April 2016 at 05:10, Pete Vander Giessen  wrote:
> >> Hi All,
> >>
> >> Thank you very much for posting this thread. I've been following the
> >> "getting started" developer's guide at
> >> https://jujucharms.com/docs/devel/getting-started, and this info got me
> >> unstuck.
> >>
> >> I figured that I'd mention that, when I ran dpkg-reconfigure, I had to
> >> create an ipv4 subnet, rather than letting lxd use a proxy, as it does
> by
> >> default on a fresh install of Xenial. I'm not sure if it's necessarily
> >> related to the bridge issue, but I figured I'd be chatty about it in
> this
> >> thread, just in case it helps someone else get themselves unblocked, too
> >> (relevant debug logs posted below my sig).
> >>
> >> Thanks again,
> >>
> >> ~ PeteVG
> >>
> >> Logs from my install, before explicitly setting up the subnet:
> >>
> >> ~$ juju bootstrap --config default-series=xenial lxd-test lxd --debug
> >> 2016-04-07 03:51:01 INFO juju.cmd supercommand.go:60 running juju
> >> [2.0-beta3
> >> gc go1.6]
> >> 2016-04-07 03:51:01 INFO cmd cmd.go:141 cloud "lxd" not found, trying
> as a
> >> provider name
> >> 2016-04-07 03:51:01 INFO cmd cmd.go:141 no credentials found, checking
> >> environment
> >> 2016-04-07 03:51:01 DEBUG juju.cmd.juju.commands bootstrap.go:363
> >> preparing
> >> controller with config: map[default-series:xenial type:lxd name:admin
> >> uuid:9925cf81-618b-4d50-8f77-b16447c921d8
> >> controller-uuid:9925cf81-618b-4d50-8f77-b16447c921d8]
> >> 2016-04-07 03:51:01 ERROR cmd supercommand.go:448 invalid config: no
> >> addresses match
> >>
> >>
> >> On Wed, Apr 6, 2016 at 5:30 PM Reed O'Brien 
> >> wrote:
> >>>
> >>> 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
> >>> same
> >>> address info, which didn't work out so slick.
> >>>
> >>> Also, you need to `systemctl stop lxd-bridge.service && systemctl
> restart
> >>> lxd.service` in the correct order.
> >>>
> >>> On Wed, Apr 6, 2016 at 2:22 PM, Andrew McDermott
> >>>  wrote:
> 
>  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, Casey Marshall
> >  wrote:
> >>
> >> On Wed, Apr 6, 2016 at 2:51 PM, Alexis Bruemmer
> >>  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 and 

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

[Reed O'Brien]

I think you need to enter the CIDR netmask as a bit len, e.g. 24 rather
than as 255.255.255.0.

See
https://github.com/reedobrien/juju-notes/blob/master/writing-a-ci-test.md
and the section on LXD for my personal notes about a working config.

HTH,
Reed

On Thu, Apr 7, 2016 at 8:14 AM, roger peppe 
wrote:

> I tried it. I get this error after typing in lots of ipv4 details:
>
> /var/lib/dpkg/info/lxd.postinst: 8: /var/lib/dpkg/info/lxd.postinst:
> arithmetic expression: expecting ')': " 5 - (255.255.255.0 / 8) "
>
> My full interaction was as follows: http://paste.ubuntu.com/15671384/
>
>
> On 7 April 2016 at 15:57, John Meinel  wrote:
> > Did you run dpkg-reconfigure lxd ? That's what I ran once I installed the
> > new lxd package and it seemed to get things working. Tycho added some
> > helpful prompts as part of "juju bootstrap" to point users in the right
> > direction if LXD looks to be improperly configured.
> >
> > https://github.com/juju/juju/pull/4984
> >
> >
> > I'm trying to land that now.
> >
> > John
> > =:->
> >
> > On Apr 7, 2016 6:19 PM, "roger peppe"  wrote:
> >
> > To add to this conversation, I have encountered this issue today
> > and have been unable to resolve it so far in the limited time
> > I've been able to spend on it.
> >
> > I'm running on Trusty; I have the new version of lxd and the
> > latest version of Juju tip.
> >
> > In my case, the issue seems to be that my lcdbr0 interface
> > has no IPv4 addresses (I've tried fiddling with /etc/default/lxd-bridge
> > and restarting various things to avail) and that the
> > utils.GetAddressForInterface
> > function excludes all IPv4 addresses. I'm thinking that it shouldn't do
> > that,
> > but that might not be the only thing that's wrong.
> >
> >
> >
> > On 7 April 2016 at 05:10, Pete Vander Giessen  wrote:
> >> Hi All,
> >>
> >> Thank you very much for posting this thread. I've been following the
> >> "getting started" developer's guide at
> >> https://jujucharms.com/docs/devel/getting-started, and this info got me
> >> unstuck.
> >>
> >> I figured that I'd mention that, when I ran dpkg-reconfigure, I had to
> >> create an ipv4 subnet, rather than letting lxd use a proxy, as it does
> by
> >> default on a fresh install of Xenial. I'm not sure if it's necessarily
> >> related to the bridge issue, but I figured I'd be chatty about it in
> this
> >> thread, just in case it helps someone else get themselves unblocked, too
> >> (relevant debug logs posted below my sig).
> >>
> >> Thanks again,
> >>
> >> ~ PeteVG
> >>
> >> Logs from my install, before explicitly setting up the subnet:
> >>
> >> ~$ juju bootstrap --config default-series=xenial lxd-test lxd --debug
> >> 2016-04-07 03:51:01 INFO juju.cmd supercommand.go:60 running juju
> >> [2.0-beta3
> >> gc go1.6]
> >> 2016-04-07 03:51:01 INFO cmd cmd.go:141 cloud "lxd" not found, trying
> as a
> >> provider name
> >> 2016-04-07 03:51:01 INFO cmd cmd.go:141 no credentials found, checking
> >> environment
> >> 2016-04-07 03:51:01 DEBUG juju.cmd.juju.commands bootstrap.go:363
> >> preparing
> >> controller with config: map[default-series:xenial type:lxd name:admin
> >> uuid:9925cf81-618b-4d50-8f77-b16447c921d8
> >> controller-uuid:9925cf81-618b-4d50-8f77-b16447c921d8]
> >> 2016-04-07 03:51:01 ERROR cmd supercommand.go:448 invalid config: no
> >> addresses match
> >>
> >>
> >> On Wed, Apr 6, 2016 at 5:30 PM Reed O'Brien 
> >> wrote:
> >>>
> >>> 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
> >>> same
> >>> address info, which didn't work out so slick.
> >>>
> >>> Also, you need to `systemctl stop lxd-bridge.service && systemctl
> restart
> >>> lxd.service` in the correct order.
> >>>
> >>> On Wed, Apr 6, 2016 at 2:22 PM, Andrew McDermott
> >>>  wrote:
> 
>  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, Casey Marshall
> >  wrote:
> >>
> >> On Wed, Apr 6, 2016 at 2:51 PM, Alexis Bruemmer
> >>  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 and 

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

[roger peppe]

I tried it. I get this error after typing in lots of ipv4 details:

/var/lib/dpkg/info/lxd.postinst: 8: /var/lib/dpkg/info/lxd.postinst:
arithmetic expression: expecting ')': " 5 - (255.255.255.0 / 8) "

My full interaction was as follows: http://paste.ubuntu.com/15671384/


On 7 April 2016 at 15:57, John Meinel  wrote:
> Did you run dpkg-reconfigure lxd ? That's what I ran once I installed the
> new lxd package and it seemed to get things working. Tycho added some
> helpful prompts as part of "juju bootstrap" to point users in the right
> direction if LXD looks to be improperly configured.
>
> https://github.com/juju/juju/pull/4984
>
>
> I'm trying to land that now.
>
> John
> =:->
>
> On Apr 7, 2016 6:19 PM, "roger peppe"  wrote:
>
> To add to this conversation, I have encountered this issue today
> and have been unable to resolve it so far in the limited time
> I've been able to spend on it.
>
> I'm running on Trusty; I have the new version of lxd and the
> latest version of Juju tip.
>
> In my case, the issue seems to be that my lcdbr0 interface
> has no IPv4 addresses (I've tried fiddling with /etc/default/lxd-bridge
> and restarting various things to avail) and that the
> utils.GetAddressForInterface
> function excludes all IPv4 addresses. I'm thinking that it shouldn't do
> that,
> but that might not be the only thing that's wrong.
>
>
>
> On 7 April 2016 at 05:10, Pete Vander Giessen  wrote:
>> Hi All,
>>
>> Thank you very much for posting this thread. I've been following the
>> "getting started" developer's guide at
>> https://jujucharms.com/docs/devel/getting-started, and this info got me
>> unstuck.
>>
>> I figured that I'd mention that, when I ran dpkg-reconfigure, I had to
>> create an ipv4 subnet, rather than letting lxd use a proxy, as it does by
>> default on a fresh install of Xenial. I'm not sure if it's necessarily
>> related to the bridge issue, but I figured I'd be chatty about it in this
>> thread, just in case it helps someone else get themselves unblocked, too
>> (relevant debug logs posted below my sig).
>>
>> Thanks again,
>>
>> ~ PeteVG
>>
>> Logs from my install, before explicitly setting up the subnet:
>>
>> ~$ juju bootstrap --config default-series=xenial lxd-test lxd --debug
>> 2016-04-07 03:51:01 INFO juju.cmd supercommand.go:60 running juju
>> [2.0-beta3
>> gc go1.6]
>> 2016-04-07 03:51:01 INFO cmd cmd.go:141 cloud "lxd" not found, trying as a
>> provider name
>> 2016-04-07 03:51:01 INFO cmd cmd.go:141 no credentials found, checking
>> environment
>> 2016-04-07 03:51:01 DEBUG juju.cmd.juju.commands bootstrap.go:363
>> preparing
>> controller with config: map[default-series:xenial type:lxd name:admin
>> uuid:9925cf81-618b-4d50-8f77-b16447c921d8
>> controller-uuid:9925cf81-618b-4d50-8f77-b16447c921d8]
>> 2016-04-07 03:51:01 ERROR cmd supercommand.go:448 invalid config: no
>> addresses match
>>
>>
>> On Wed, Apr 6, 2016 at 5:30 PM Reed O'Brien 
>> wrote:
>>>
>>> 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
>>> same
>>> address info, which didn't work out so slick.
>>>
>>> Also, you need to `systemctl stop lxd-bridge.service && systemctl restart
>>> lxd.service` in the correct order.
>>>
>>> On Wed, Apr 6, 2016 at 2:22 PM, Andrew McDermott
>>>  wrote:

 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, Casey Marshall
>  wrote:
>>
>> On Wed, Apr 6, 2016 at 2:51 PM, Alexis Bruemmer
>>  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 and Juju expecting lxcbr0.
>>> Thanks
>>> to the heads up and help from the LXD team there is a fix for this in
>>> Juju
>>> master that will be available in the release next week.  However,
>>> until then
>>> Juju 2.0-beta3 will not work with the latest LXD (v2.0.0-rc8).
>>
>>
>> If you `dpkg-reconfigure lxd` and name the bridge "lxcbr0", does this
>> work for beta3? I've been able to bootstrap with latest LXD and
>> current Juju
>> master (beta4) by configuring LXD this way.
>>
>>>
>>>
>>> Alexis
>>>
>>> --

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

[roger peppe]

I tried it. I get this error after typing in lots of ipv4 details:

/var/lib/dpkg/info/lxd.postinst: 8: /var/lib/dpkg/info/lxd.postinst:
arithmetic expression: expecting ')': " 5 - (255.255.255.0 / 8) "

My full interaction was as follows: http://paste.ubuntu.com/15671384/


On 7 April 2016 at 15:57, John Meinel  wrote:
> Did you run dpkg-reconfigure lxd ? That's what I ran once I installed the
> new lxd package and it seemed to get things working. Tycho added some
> helpful prompts as part of "juju bootstrap" to point users in the right
> direction if LXD looks to be improperly configured.
>
> https://github.com/juju/juju/pull/4984
>
>
> I'm trying to land that now.
>
> John
> =:->
>
> On Apr 7, 2016 6:19 PM, "roger peppe"  wrote:
>
> To add to this conversation, I have encountered this issue today
> and have been unable to resolve it so far in the limited time
> I've been able to spend on it.
>
> I'm running on Trusty; I have the new version of lxd and the
> latest version of Juju tip.
>
> In my case, the issue seems to be that my lcdbr0 interface
> has no IPv4 addresses (I've tried fiddling with /etc/default/lxd-bridge
> and restarting various things to avail) and that the
> utils.GetAddressForInterface
> function excludes all IPv4 addresses. I'm thinking that it shouldn't do
> that,
> but that might not be the only thing that's wrong.
>
>
>
> On 7 April 2016 at 05:10, Pete Vander Giessen  wrote:
>> Hi All,
>>
>> Thank you very much for posting this thread. I've been following the
>> "getting started" developer's guide at
>> https://jujucharms.com/docs/devel/getting-started, and this info got me
>> unstuck.
>>
>> I figured that I'd mention that, when I ran dpkg-reconfigure, I had to
>> create an ipv4 subnet, rather than letting lxd use a proxy, as it does by
>> default on a fresh install of Xenial. I'm not sure if it's necessarily
>> related to the bridge issue, but I figured I'd be chatty about it in this
>> thread, just in case it helps someone else get themselves unblocked, too
>> (relevant debug logs posted below my sig).
>>
>> Thanks again,
>>
>> ~ PeteVG
>>
>> Logs from my install, before explicitly setting up the subnet:
>>
>> ~$ juju bootstrap --config default-series=xenial lxd-test lxd --debug
>> 2016-04-07 03:51:01 INFO juju.cmd supercommand.go:60 running juju
>> [2.0-beta3
>> gc go1.6]
>> 2016-04-07 03:51:01 INFO cmd cmd.go:141 cloud "lxd" not found, trying as a
>> provider name
>> 2016-04-07 03:51:01 INFO cmd cmd.go:141 no credentials found, checking
>> environment
>> 2016-04-07 03:51:01 DEBUG juju.cmd.juju.commands bootstrap.go:363
>> preparing
>> controller with config: map[default-series:xenial type:lxd name:admin
>> uuid:9925cf81-618b-4d50-8f77-b16447c921d8
>> controller-uuid:9925cf81-618b-4d50-8f77-b16447c921d8]
>> 2016-04-07 03:51:01 ERROR cmd supercommand.go:448 invalid config: no
>> addresses match
>>
>>
>> On Wed, Apr 6, 2016 at 5:30 PM Reed O'Brien 
>> wrote:
>>>
>>> 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
>>> same
>>> address info, which didn't work out so slick.
>>>
>>> Also, you need to `systemctl stop lxd-bridge.service && systemctl restart
>>> lxd.service` in the correct order.
>>>
>>> On Wed, Apr 6, 2016 at 2:22 PM, Andrew McDermott
>>>  wrote:

 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, Casey Marshall
>  wrote:
>>
>> On Wed, Apr 6, 2016 at 2:51 PM, Alexis Bruemmer
>>  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 and Juju expecting lxcbr0.
>>> Thanks
>>> to the heads up and help from the LXD team there is a fix for this in
>>> Juju
>>> master that will be available in the release next week.  However,
>>> until then
>>> Juju 2.0-beta3 will not work with the latest LXD (v2.0.0-rc8).
>>
>>
>> If you `dpkg-reconfigure lxd` and name the bridge "lxcbr0", does this
>> work for beta3? I've been able to bootstrap with latest LXD and
>> current Juju
>> master (beta4) by configuring LXD this way.
>>
>>>
>>>
>>> Alexis
>>>
>>> --

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

[John Meinel]

Did you run dpkg-reconfigure lxd ? That's what I ran once I installed the
new lxd package and it seemed to get things working. Tycho added some
helpful prompts as part of "juju bootstrap" to point users in the right
direction if LXD looks to be improperly configured.

https://github.com/juju/juju/pull/4984


I'm trying to land that now.

John
=:->
On Apr 7, 2016 6:19 PM, "roger peppe"  wrote:

To add to this conversation, I have encountered this issue today
and have been unable to resolve it so far in the limited time
I've been able to spend on it.

I'm running on Trusty; I have the new version of lxd and the
latest version of Juju tip.

In my case, the issue seems to be that my lcdbr0 interface
has no IPv4 addresses (I've tried fiddling with /etc/default/lxd-bridge
and restarting various things to avail) and that the
utils.GetAddressForInterface
function excludes all IPv4 addresses. I'm thinking that it shouldn't do
that,
but that might not be the only thing that's wrong.



On 7 April 2016 at 05:10, Pete Vander Giessen  wrote:
> Hi All,
>
> Thank you very much for posting this thread. I've been following the
> "getting started" developer's guide at
> https://jujucharms.com/docs/devel/getting-started, and this info got me
> unstuck.
>
> I figured that I'd mention that, when I ran dpkg-reconfigure, I had to
> create an ipv4 subnet, rather than letting lxd use a proxy, as it does by
> default on a fresh install of Xenial. I'm not sure if it's necessarily
> related to the bridge issue, but I figured I'd be chatty about it in this
> thread, just in case it helps someone else get themselves unblocked, too
> (relevant debug logs posted below my sig).
>
> Thanks again,
>
> ~ PeteVG
>
> Logs from my install, before explicitly setting up the subnet:
>
> ~$ juju bootstrap --config default-series=xenial lxd-test lxd --debug
> 2016-04-07 03:51:01 INFO juju.cmd supercommand.go:60 running juju
[2.0-beta3
> gc go1.6]
> 2016-04-07 03:51:01 INFO cmd cmd.go:141 cloud "lxd" not found, trying as a
> provider name
> 2016-04-07 03:51:01 INFO cmd cmd.go:141 no credentials found, checking
> environment
> 2016-04-07 03:51:01 DEBUG juju.cmd.juju.commands bootstrap.go:363
preparing
> controller with config: map[default-series:xenial type:lxd name:admin
> uuid:9925cf81-618b-4d50-8f77-b16447c921d8
> controller-uuid:9925cf81-618b-4d50-8f77-b16447c921d8]
> 2016-04-07 03:51:01 ERROR cmd supercommand.go:448 invalid config: no
> addresses match
>
>
> On Wed, Apr 6, 2016 at 5:30 PM Reed O'Brien 
> wrote:
>>
>> 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
same
>> address info, which didn't work out so slick.
>>
>> Also, you need to `systemctl stop lxd-bridge.service && systemctl restart
>> lxd.service` in the correct order.
>>
>> On Wed, Apr 6, 2016 at 2:22 PM, Andrew McDermott
>>  wrote:
>>>
>>> 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, Casey Marshall
  wrote:
>
> On Wed, Apr 6, 2016 at 2:51 PM, Alexis Bruemmer
>  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 and Juju expecting lxcbr0.
Thanks
>> to the heads up and help from the LXD team there is a fix for this
in Juju
>> master that will be available in the release next week.  However,
until then
>> Juju 2.0-beta3 will not work with the latest LXD (v2.0.0-rc8).
>
>
> If you `dpkg-reconfigure lxd` and name the bridge "lxcbr0", does this
> work for beta3? I've been able to bootstrap with latest LXD and
current Juju
> master (beta4) by configuring LXD this way.
>
>>
>>
>> Alexis
>>
>> --
>> Alexis Bruemmer
>> Juju Core Manager, Canonical Ltd.
>> (503) 686-5018
>> alexis.bruem...@canonical.com
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>


 --
 Juju-dev mailing list
 

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

[John Meinel]

Did you run dpkg-reconfigure lxd ? That's what I ran once I installed the
new lxd package and it seemed to get things working. Tycho added some
helpful prompts as part of "juju bootstrap" to point users in the right
direction if LXD looks to be improperly configured.

https://github.com/juju/juju/pull/4984


I'm trying to land that now.

John
=:->
On Apr 7, 2016 6:19 PM, "roger peppe"  wrote:

To add to this conversation, I have encountered this issue today
and have been unable to resolve it so far in the limited time
I've been able to spend on it.

I'm running on Trusty; I have the new version of lxd and the
latest version of Juju tip.

In my case, the issue seems to be that my lcdbr0 interface
has no IPv4 addresses (I've tried fiddling with /etc/default/lxd-bridge
and restarting various things to avail) and that the
utils.GetAddressForInterface
function excludes all IPv4 addresses. I'm thinking that it shouldn't do
that,
but that might not be the only thing that's wrong.



On 7 April 2016 at 05:10, Pete Vander Giessen  wrote:
> Hi All,
>
> Thank you very much for posting this thread. I've been following the
> "getting started" developer's guide at
> https://jujucharms.com/docs/devel/getting-started, and this info got me
> unstuck.
>
> I figured that I'd mention that, when I ran dpkg-reconfigure, I had to
> create an ipv4 subnet, rather than letting lxd use a proxy, as it does by
> default on a fresh install of Xenial. I'm not sure if it's necessarily
> related to the bridge issue, but I figured I'd be chatty about it in this
> thread, just in case it helps someone else get themselves unblocked, too
> (relevant debug logs posted below my sig).
>
> Thanks again,
>
> ~ PeteVG
>
> Logs from my install, before explicitly setting up the subnet:
>
> ~$ juju bootstrap --config default-series=xenial lxd-test lxd --debug
> 2016-04-07 03:51:01 INFO juju.cmd supercommand.go:60 running juju
[2.0-beta3
> gc go1.6]
> 2016-04-07 03:51:01 INFO cmd cmd.go:141 cloud "lxd" not found, trying as a
> provider name
> 2016-04-07 03:51:01 INFO cmd cmd.go:141 no credentials found, checking
> environment
> 2016-04-07 03:51:01 DEBUG juju.cmd.juju.commands bootstrap.go:363
preparing
> controller with config: map[default-series:xenial type:lxd name:admin
> uuid:9925cf81-618b-4d50-8f77-b16447c921d8
> controller-uuid:9925cf81-618b-4d50-8f77-b16447c921d8]
> 2016-04-07 03:51:01 ERROR cmd supercommand.go:448 invalid config: no
> addresses match
>
>
> On Wed, Apr 6, 2016 at 5:30 PM Reed O'Brien 
> wrote:
>>
>> 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
same
>> address info, which didn't work out so slick.
>>
>> Also, you need to `systemctl stop lxd-bridge.service && systemctl restart
>> lxd.service` in the correct order.
>>
>> On Wed, Apr 6, 2016 at 2:22 PM, Andrew McDermott
>>  wrote:
>>>
>>> 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, Casey Marshall
  wrote:
>
> On Wed, Apr 6, 2016 at 2:51 PM, Alexis Bruemmer
>  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 and Juju expecting lxcbr0.
Thanks
>> to the heads up and help from the LXD team there is a fix for this
in Juju
>> master that will be available in the release next week.  However,
until then
>> Juju 2.0-beta3 will not work with the latest LXD (v2.0.0-rc8).
>
>
> If you `dpkg-reconfigure lxd` and name the bridge "lxcbr0", does this
> work for beta3? I've been able to bootstrap with latest LXD and
current Juju
> master (beta4) by configuring LXD this way.
>
>>
>>
>> Alexis
>>
>> --
>> Alexis Bruemmer
>> Juju Core Manager, Canonical Ltd.
>> (503) 686-5018
>> alexis.bruem...@canonical.com
>>
>> --
>> Juju mailing list
>> j...@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>


 --
 Juju-dev mailing list
 

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

[roger peppe]

To add to this conversation, I have encountered this issue today
and have been unable to resolve it so far in the limited time
I've been able to spend on it.

I'm running on Trusty; I have the new version of lxd and the
latest version of Juju tip.

In my case, the issue seems to be that my lcdbr0 interface
has no IPv4 addresses (I've tried fiddling with /etc/default/lxd-bridge
and restarting various things to avail) and that the
utils.GetAddressForInterface
function excludes all IPv4 addresses. I'm thinking that it shouldn't do that,
but that might not be the only thing that's wrong.



On 7 April 2016 at 05:10, Pete Vander Giessen  wrote:
> Hi All,
>
> Thank you very much for posting this thread. I've been following the
> "getting started" developer's guide at
> https://jujucharms.com/docs/devel/getting-started, and this info got me
> unstuck.
>
> I figured that I'd mention that, when I ran dpkg-reconfigure, I had to
> create an ipv4 subnet, rather than letting lxd use a proxy, as it does by
> default on a fresh install of Xenial. I'm not sure if it's necessarily
> related to the bridge issue, but I figured I'd be chatty about it in this
> thread, just in case it helps someone else get themselves unblocked, too
> (relevant debug logs posted below my sig).
>
> Thanks again,
>
> ~ PeteVG
>
> Logs from my install, before explicitly setting up the subnet:
>
> ~$ juju bootstrap --config default-series=xenial lxd-test lxd --debug
> 2016-04-07 03:51:01 INFO juju.cmd supercommand.go:60 running juju [2.0-beta3
> gc go1.6]
> 2016-04-07 03:51:01 INFO cmd cmd.go:141 cloud "lxd" not found, trying as a
> provider name
> 2016-04-07 03:51:01 INFO cmd cmd.go:141 no credentials found, checking
> environment
> 2016-04-07 03:51:01 DEBUG juju.cmd.juju.commands bootstrap.go:363 preparing
> controller with config: map[default-series:xenial type:lxd name:admin
> uuid:9925cf81-618b-4d50-8f77-b16447c921d8
> controller-uuid:9925cf81-618b-4d50-8f77-b16447c921d8]
> 2016-04-07 03:51:01 ERROR cmd supercommand.go:448 invalid config: no
> addresses match
>
>
> On Wed, Apr 6, 2016 at 5:30 PM Reed O'Brien 
> wrote:
>>
>> 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 same
>> address info, which didn't work out so slick.
>>
>> Also, you need to `systemctl stop lxd-bridge.service && systemctl restart
>> lxd.service` in the correct order.
>>
>> On Wed, Apr 6, 2016 at 2:22 PM, Andrew McDermott
>>  wrote:
>>>
>>> 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, Casey Marshall
  wrote:
>
> On Wed, Apr 6, 2016 at 2:51 PM, Alexis Bruemmer
>  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 and Juju expecting lxcbr0.  
>> Thanks
>> to the heads up and help from the LXD team there is a fix for this in 
>> Juju
>> master that will be available in the release next week.  However, until 
>> then
>> Juju 2.0-beta3 will not work with the latest LXD (v2.0.0-rc8).
>
>
> If you `dpkg-reconfigure lxd` and name the bridge "lxcbr0", does this
> work for beta3? I've been able to bootstrap with latest LXD and current 
> Juju
> master (beta4) by configuring LXD this way.
>
>>
>>
>> Alexis
>>
>> --
>> Alexis Bruemmer
>> Juju Core Manager, Canonical Ltd.
>> (503) 686-5018
>> alexis.bruem...@canonical.com
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>


 --
 Juju-dev mailing list
 juju-...@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev

>>>
>>>
>>>
>>> --
>>> Andrew McDermott 
>>> Juju Core Sapphire team 
>>>
>>> --
>>> Juju-dev mailing list
>>> juju-...@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> 

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

[roger peppe]

To add to this conversation, I have encountered this issue today
and have been unable to resolve it so far in the limited time
I've been able to spend on it.

I'm running on Trusty; I have the new version of lxd and the
latest version of Juju tip.

In my case, the issue seems to be that my lcdbr0 interface
has no IPv4 addresses (I've tried fiddling with /etc/default/lxd-bridge
and restarting various things to avail) and that the
utils.GetAddressForInterface
function excludes all IPv4 addresses. I'm thinking that it shouldn't do that,
but that might not be the only thing that's wrong.



On 7 April 2016 at 05:10, Pete Vander Giessen  wrote:
> Hi All,
>
> Thank you very much for posting this thread. I've been following the
> "getting started" developer's guide at
> https://jujucharms.com/docs/devel/getting-started, and this info got me
> unstuck.
>
> I figured that I'd mention that, when I ran dpkg-reconfigure, I had to
> create an ipv4 subnet, rather than letting lxd use a proxy, as it does by
> default on a fresh install of Xenial. I'm not sure if it's necessarily
> related to the bridge issue, but I figured I'd be chatty about it in this
> thread, just in case it helps someone else get themselves unblocked, too
> (relevant debug logs posted below my sig).
>
> Thanks again,
>
> ~ PeteVG
>
> Logs from my install, before explicitly setting up the subnet:
>
> ~$ juju bootstrap --config default-series=xenial lxd-test lxd --debug
> 2016-04-07 03:51:01 INFO juju.cmd supercommand.go:60 running juju [2.0-beta3
> gc go1.6]
> 2016-04-07 03:51:01 INFO cmd cmd.go:141 cloud "lxd" not found, trying as a
> provider name
> 2016-04-07 03:51:01 INFO cmd cmd.go:141 no credentials found, checking
> environment
> 2016-04-07 03:51:01 DEBUG juju.cmd.juju.commands bootstrap.go:363 preparing
> controller with config: map[default-series:xenial type:lxd name:admin
> uuid:9925cf81-618b-4d50-8f77-b16447c921d8
> controller-uuid:9925cf81-618b-4d50-8f77-b16447c921d8]
> 2016-04-07 03:51:01 ERROR cmd supercommand.go:448 invalid config: no
> addresses match
>
>
> On Wed, Apr 6, 2016 at 5:30 PM Reed O'Brien 
> wrote:
>>
>> 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 same
>> address info, which didn't work out so slick.
>>
>> Also, you need to `systemctl stop lxd-bridge.service && systemctl restart
>> lxd.service` in the correct order.
>>
>> On Wed, Apr 6, 2016 at 2:22 PM, Andrew McDermott
>>  wrote:
>>>
>>> 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, Casey Marshall
  wrote:
>
> On Wed, Apr 6, 2016 at 2:51 PM, Alexis Bruemmer
>  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 and Juju expecting lxcbr0.  
>> Thanks
>> to the heads up and help from the LXD team there is a fix for this in 
>> Juju
>> master that will be available in the release next week.  However, until 
>> then
>> Juju 2.0-beta3 will not work with the latest LXD (v2.0.0-rc8).
>
>
> If you `dpkg-reconfigure lxd` and name the bridge "lxcbr0", does this
> work for beta3? I've been able to bootstrap with latest LXD and current 
> Juju
> master (beta4) by configuring LXD this way.
>
>>
>>
>> Alexis
>>
>> --
>> Alexis Bruemmer
>> Juju Core Manager, Canonical Ltd.
>> (503) 686-5018
>> alexis.bruem...@canonical.com
>>
>> --
>> Juju mailing list
>> j...@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>


 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev

>>>
>>>
>>>
>>> --
>>> Andrew McDermott 
>>> Juju Core Sapphire team 
>>>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> 

Re: Action return value too long for commandline

[Mark Shuttleworth]

Right. I think what you're describing really is an object exchange
mechanism / store with appropriate permissioning so other peers can see
an object a unit places there.

That's basically fine because it keeps the internal implementation of
the charm internal - only peer units with the same charm get to see the
objects, so the code will definitely know what to expect.

If we also allow operators to see those objects, we might have scripts
written to expect them, and we need to think if that's good. And that's
DOUBLY true if we want to think about exposing those objects across
relations, because it becomes yet another way to add friction to charm
substitutions - the new charm must also export all the same expected
objects.

But the first part sounds definitely +1

Mark

On 05/04/16 22:53, Merlijn Sebrechts wrote:
> Hi Mark
>
>
> What's your opinion to adding outflowing and peer-flowing capabilities to
> resources? Outflowing: from charm to operator, peer-flowing: from charm to
> charm. I'm not sure if there is such a big conceptual difference between
> inflowing, outflowing and peer-flowing. I have the tendency to see an
> operator as just another Charm. This might become reality when the "stacks"
> functionality gets introduced because then there will be a charm-like
> entity that manages a bunch of charms... This might make that transition
> easier...
>
>
>
> Kind regards
> Merlijn
>
> 2016-04-05 2:42 GMT-07:00 Mark Shuttleworth :
>
>> We should definitely have a mechanism for large-file output from actions
>> and other hooks. I think resources are "inward flowing", they come from the
>> charmer or they are provided by the operator. You're looking for "outward
>> flowing" blobs.
>>
>> As I recall, the intention was that actions could drop results into the
>> controller in a way that was friendly to large BLOB results. That's why we
>> have an async action output and result mechanism. I reckon it would be fine
>> to use resources for input to actions (there would just be a specific
>> user-provided resource name and there would be only one version of that at
>> any given time), but we want to make sure that output can also be
>> efficiently handled regardless of size, so if we need to improve that,
>> let's crack on.
>>
>> Mark
>>
>>
>> On 04/04/16 16:56, Merlijn Sebrechts wrote:
>>
>> Hi Stuart
>>
>>
>> Thanks for this explanation. 16MB is definitely a step in the right
>> direction. However, in the future I'll need to transfer even bigger files.
>> Is there a possibility for using resources for this in the future? It would
>> be great if an action could upload a file to the resources server so the
>> admin can download it from there.
>>
>>
>>
>> Kind regards
>> Merlijn Sebrechts
>>
>> 2016-04-03 19:34 GMT-07:00 Stuart Bishop  
>> :
>>
>>
>> On 4 April 2016 at 02:00, Merlijn Sebrechts  
>> 
>> wrote:
>>
>> Hi all
>>
>>
>> The apache-kafka charm has an action "read-topic" that can return a lot
>>
>> of
>>
>> data. Sometimes, this data is too long to be passed to `action-set` by
>> commandline. You get the following error:
>>
>> Traceback (most recent call last):
>>   File "actions/read-topic", line 36, in 
>> hookenv.action_set({'output': output})
>>   File
>> "/usr/local/lib/python2.7/dist-packages/charmhelpers/core/hookenv.py",
>>
>> line
>>
>> 615, in action_set
>> subprocess.check_call(cmd)
>>   File "/usr/lib/python2.7/subprocess.py", line 535, in check_call
>> retcode = call(*popenargs, **kwargs)
>>   File "/usr/lib/python2.7/subprocess.py", line 522, in call
>> return Popen(*popenargs, **kwargs).wait()
>>   File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
>> errread, errwrite)
>>   File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
>> raise child_exception
>> OSError: [Errno 7] Argument list too long
>>
>>
>> Is there any way to pass a file to action-set?
>>
>> This bug affects many of the Juju tools causing charms to fail at
>> scale. https://bugs.launchpad.net/juju-core/+bug/1437366
>> (relation-set) is the only one I know of that has been 
>> fixed.https://bugs.launchpad.net/juju-core/+bug/1274460 (juju-log) is still
>> open. leader-set also fails now I think of it, but I haven't tripped
>> over that one (it limits scalability the way I'm using leadershp
>> settings, but I should be able to squeeze out several hundred units).
>> Maybe we can use the opportunity to fix quoting and encoding issues.
>>
>> I suspect if you can get past command line length limitations, I
>> suspect the next glass ceiling is a 16MB document size limit in
>> MongoDB (which is large enough to not need fixing?)
>>
>> --
>> Stuart Bishop  
>>
>>
>>
>>
>>



-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 

Re: Unable to kill-controller

[Aaron Bentley]

-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 successfully destroyed without resorting to
the provider", status 1 = "I had to resort to the provider to
destroy", status 2+ = "I did not destroy"?

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXBmk4AAoJEK84cMOcf+9hjwgH/RqcX5OqVKx7SoxCbjnbj7sk
O5UKWCbn00F2LsGxfuwM3jL94dXFO0q854BHWSBsjOJUD3i4CdKAlI9MYBkCYOk6
CEYnG8U+12LG+g56tAVEGLhYJ/wlA7hJVr/64xlQw1AiNliqKpNWaLftTMGUs6DC
gUQ06EEqkrFQwyh6A0DB0c5FbpX9sA5W+TpGsJJz+TTsJVxBycaLJQF06ZbyxREX
LEar/v8sr+4uZia+OrJofynGUVxt5Ub6p4+XNBnMF4oWkg2kYjmTNnGduUFv9mKk
bLuIYrOJzz6l8ZiTn6VrPI7Ztad+6+CIPcITaw+s3wMZ8pCT0zRNNk6OxZREXcs=
=hyhy
-END PGP SIGNATURE-

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: New juju in ubuntu

[Martin Packman]

On 06/04/2016, Stuart Bishop  wrote:
>
> How do our plugins know what version of juju is in play? Can they
> assume that the 'juju' binary found on the path is the juju that
> invoked the plugin, or is there some other way to tell using
> environment variables or such? Or will all the juju plugins just fail
> if they are invoked from the non-default juju version?

The new packaging uses wrapping scripts for 'juju-1' and 'juju-2.0'
that prepend PATH with the version-specific directories. The default
/usr/bin/juju is just a symlink though, so invoking outside the
context of the wrappers will still be ambiguous. I think we do need a
better solution here.

Martin

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: New juju in ubuntu

[Stuart Bishop]

On 7 April 2016 at 16:46, roger peppe  wrote:
> On 7 April 2016 at 10:17, Stuart Bishop  wrote:
>> On 7 April 2016 at 16:03, roger peppe  wrote:
>>> On 7 April 2016 at 09:38, Tim Penhey  wrote:
 We could probably set an environment variable for the plugin called
 JUJU_BIN that is the juju that invoked it.

 Wouldn't be too hard.
>>>
>>> How does that stop old plugins failing because the new juju is trying
>>> to use them?
>>>
>>> An alternative possibility: name all new plugins with the prefix "juju2-" 
>>> rather
>>> than "juju".
>>
>> I've opened https://bugs.launchpad.net/juju-core/+bug/1567296 to track this.
>>
>> Prepending the $PATH is not hard either - just override the
>> environment in the exec() call.
>>
>> The nicest approach may be to not use 'juju1', 'juju2' and 'juju' but
>> instead just 'juju'. It would be a thin wrapper that sets the $PATH
>> and invokes the correct binary based on some configuration such as an
>> environment variable. This would fix plugins, and lots of other stuff
>> that are about to break too such as deployment scripts, test suites
>> etc.
>
> There are actually two problems here. One is the fact that plugins
> use the Juju binary. For that, setting the PATH might well be the right thing.
>
> But there's also a problem with other plugins that use the Juju API
> directly (they might be written in Go, for example) and therefore
> implicitly assume the that they're talking to a juju 1 or juju 2 environment.
> Since local configuration files have changed and the API has changed, it's
> important that a plugin written for Go 1 won't be invoked by a juju 2
> binary.

If juju 2.x changed the plugin prefix from juju- to juju2-, that would
also solve the issue of juju 2.x specific plugins showing up in juju
1.x's command line help and vice versa.

-- 
Stuart Bishop 

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: New juju in ubuntu

[roger peppe]

On 7 April 2016 at 10:17, Stuart Bishop  wrote:
> On 7 April 2016 at 16:03, roger peppe  wrote:
>> On 7 April 2016 at 09:38, Tim Penhey  wrote:
>>> We could probably set an environment variable for the plugin called
>>> JUJU_BIN that is the juju that invoked it.
>>>
>>> Wouldn't be too hard.
>>
>> How does that stop old plugins failing because the new juju is trying
>> to use them?
>>
>> An alternative possibility: name all new plugins with the prefix "juju2-" 
>> rather
>> than "juju".
>
> I've opened https://bugs.launchpad.net/juju-core/+bug/1567296 to track this.
>
> Prepending the $PATH is not hard either - just override the
> environment in the exec() call.
>
> The nicest approach may be to not use 'juju1', 'juju2' and 'juju' but
> instead just 'juju'. It would be a thin wrapper that sets the $PATH
> and invokes the correct binary based on some configuration such as an
> environment variable. This would fix plugins, and lots of other stuff
> that are about to break too such as deployment scripts, test suites
> etc.

There are actually two problems here. One is the fact that plugins
use the Juju binary. For that, setting the PATH might well be the right thing.

But there's also a problem with other plugins that use the Juju API
directly (they might be written in Go, for example) and therefore
implicitly assume the that they're talking to a juju 1 or juju 2 environment.
Since local configuration files have changed and the API has changed, it's
important that a plugin written for Go 1 won't be invoked by a juju 2
binary.

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: New juju in ubuntu

[Stuart Bishop]

On 7 April 2016 at 16:03, roger peppe  wrote:
> On 7 April 2016 at 09:38, Tim Penhey  wrote:
>> We could probably set an environment variable for the plugin called
>> JUJU_BIN that is the juju that invoked it.
>>
>> Wouldn't be too hard.
>
> How does that stop old plugins failing because the new juju is trying
> to use them?
>
> An alternative possibility: name all new plugins with the prefix "juju2-" 
> rather
> than "juju".

I've opened https://bugs.launchpad.net/juju-core/+bug/1567296 to track this.

Prepending the $PATH is not hard either - just override the
environment in the exec() call.

The nicest approach may be to not use 'juju1', 'juju2' and 'juju' but
instead just 'juju'. It would be a thin wrapper that sets the $PATH
and invokes the correct binary based on some configuration such as an
environment variable. This would fix plugins, and lots of other stuff
that are about to break too such as deployment scripts, test suites
etc.

-- 
Stuart Bishop 

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: New juju in ubuntu

[roger peppe]

On 7 April 2016 at 09:38, Tim Penhey  wrote:
> We could probably set an environment variable for the plugin called
> JUJU_BIN that is the juju that invoked it.
>
> Wouldn't be too hard.

How does that stop old plugins failing because the new juju is trying
to use them?

An alternative possibility: name all new plugins with the prefix "juju2-" rather
than "juju".

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: New juju in ubuntu

[Tim Penhey]

We could probably set an environment variable for the plugin called
JUJU_BIN that is the juju that invoked it.

Wouldn't be too hard.

Tim

On 07/04/16 17:25, Stuart Bishop wrote:
> 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 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, versions 1 and 2 have to be co-installable, and when upgrading to
 xenial users should get the new version without their existing working
 juju being removed.

 There are several ways to accomplish that, but based on feedback from
 the release team, we switched from using update-alternatives to having
 'juju' on xenial always be 2.0, and exposing the 1.X client via a
 'juju-1' binary wrapper. Existing scripts can either be changed to use
 the new name, or add the version-specific binaries directory
 '/var/lib/juju-1.25/bin' to the path.
>>>
>>> How do our plugins know what version of juju is in play? Can they
>>> assume that the 'juju' binary found on the path is the juju that
>>> invoked the plugin, or is there some other way to tell using
>>> environment variables or such? Or will all the juju plugins just fail
>>> if they are invoked from the non-default juju version?
>>
>>
>> You can invoke `juju version` from within the plugin and parse the output.
>> That's what I've been doing when I need to distinguish functionality.
> 
> That seems fine if you are invoking the plugin from the default
> unnumbered 'juju'. But running 'juju2 wait' will mean that juju-wait
> will be executing juju 1.x commands and fail. And conversely running
> 'juju1 wait' will invoke juju 2.x and probably fail.
> 
> I think the plugin API needs to be extended to support allowing
> multiple juju versions to coexist. An environment variable would do
> the trick but require every plugin to be fixed. Altering $PATH so
> 'juju' runs the correct juju would allow existing plugins to run
> unmodified (the bulk of them will work with both juju1 and juju2,
> since the cli is similar enough that many plugins will work
> unmodified.
> 


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Unable to kill-controller

[roger peppe]

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 this command will always need to remain around
and available to normal users, because people will always have
ways of managing instances behind Juju's back.
For example, people can terminate ec2 instances directly in the AWS console - it
might be inadvisable but it happens. The cloud is a complex
environment and things can fail (even if we write Juju perfectly)
in many ways.

My vote would be for a single command (destroy-controller)
which attempts to "do the right thing"
in all circumstances. Before attempting the shutdown and before
prompting the user for confirmation, it would try to connect to the API.
If it fails to connect to the API, the interactive confirmation prompt
would say something like "Cannot connect to controller. Do you want
to forcefully destroy all instances and other associated resources?",
different from the usual prompt.

With the --force flag, it would also try to connect to the controller
before destroying resources (same as kill-controller now).
With -y but without --force, it would not fall back to destroying
resources directly.

That way the confirmation message actually contains some useful info -
you get some feedback as to what's going on and we don't have
two subtly differently named commands.

  cheers,
rog.

On 7 April 2016 at 05:54, Andrew Wilkins  wrote:
> 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 reason I
>> find kill-controller easier to remember and type.
>>
>> Given Rick's fair position that having to kill I'd a sign of failure on
>> our part, what if:
>> 1. We stop being safe. People will be forced into a juju
>> destroy-controller || juju kill-controller position but that let's us
>> separate concerns.
>> 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.
>
> SGTM. That will go further to discouraging kill-controller except when
> really necessary.
>>
>> 3. I personally like "forget-controller" over purge, and I don't like
>> "destroy, but don't actually destroy" type of forgetting.
>>
>> John
>> =:->
>>
>> On Apr 7, 2016 4:36 AM, "Rick Harding"  wrote:
>>>
>>>
>>>
>>> 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 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 controller, destroy-controller.


 I think it would be better if we hid kill-controller, but it's clear
 from the bugs that people *are* using kill-controller and expecting it to 
 be
 more or less safe to use.
>>>
>>>
>>> But this comes back to what started this. People are using it because
>>> destroy-model isn't working for them. It's one part bug that it's not the
>>> reverse of bootstrap in its current form and one part that we've broken
>>> cleanup between betas so folks are looking for something that works. People
>>> are looking for it because they've got no choice.
>>>
>>>

 What about this scenario:
 - Alice bootstraps, and adds user Bob with admin access.
 - Bob registers the controller.
 
 - The controller is still running and available, but Bob no longer needs
 access to it.

 How does Bob remove the controller from his client without destroying
 it? He's an admin, so "destroy-controller" will happily destroy everything.

 If we add a flag to destroy-controller to only clean up the cache, then
 "oops, I forgot to add the flag" and now all the models are gone.

>>>
>>> Agree that this is a mess. This is part that we don't have a way to give
>>> folks access without making them admins. I've got this towards the top of
>>> our 16.10 roadmap. I'd rather we did something temp with a plugin here or
>>> the like until we can get a real solution in place. This does bring up how
>>> this is going to work with other hosted model solutions.
>>>
>
> I don't feel that adding another command for another way to remove a
> controller from list-controllers is something