# 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:
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,
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
> 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
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:
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
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
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.
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
-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
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?
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
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
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
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?
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
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
17 matches
Mail list logo