This was a custom build to verify a fix from the team today. It wasn't distributed. The team is working to land the changes today for the RC1 release tomorrow now that it's been verified to work for a couple of folks.
On Mon, Sep 19, 2016 at 4:52 PM Ryan Beisner <ryan.beis...@canonical.com> wrote: > Where can I get fresh RC builds? > > > On Mon, Sep 19, 2016 at 1:52 PM, Corey Bryant <corey.bry...@canonical.com> > wrote: > >> I just wanted to follow up on this thread to say I tested with a >> pre-release of juju rc1 and it fixed up the issues I was hitting. >> >> On Sat, Sep 17, 2016 at 9:04 AM, Dimiter Naydenov < >> dimiter.nayde...@canonical.com> wrote: >> >>> Hey Corey, >>> >>> That specific error I haven't seen at that stage - allocating container >>> addresses. Can you please paste the machine-0.log as well? Are you able >>> to consistently reproduce this or it's intermittent? >>> >>> Cheers, >>> Dimiter >>> >>> On 09/17/2016 12:17 AM, Corey Bryant wrote: >>> > >>> > >>> > On Thu, Sep 1, 2016 at 4:25 AM, Dimiter Naydenov >>> > <dimiter.nayde...@canonical.com <mailto:dimiter.nayde...@canonical.com >>> >> >>> > wrote: >>> > >>> > Hello! >>> > >>> > When using juju 2.0 on maas 1.9 or 2.0, you should get lxd >>> containers >>> > provisioned with as many interfaces as their host machine has, >>> because >>> > we're creating bridges on all configured host interfaces at >>> initial boot >>> > (e.g. eth0 becomes br-eth0, ens4.250 - br-ens4.250 and so on). >>> Nothing >>> > needs configuring to get this behaviour, but there's a caveat: >>> > >>> > In order for the above to work, there's a limitation currently >>> being >>> > addressed - all interfaces on the host machine in MAAS need to be >>> linked >>> > to a subnet and have an IP address configured - either as Static or >>> > Auto, but not DHCP or Unconfigured. Otherwise the process of >>> allocating >>> > addresses for the container (represented as a MAAS Device, visible >>> on >>> > the host node's details page in MAAS UI under Containers and VMs) >>> can >>> > fail half way through and Juju will instead fall back to a the >>> single >>> > NIC LXD default profile, using lxdbr0 on a local subnet. You can >>> tell >>> > whether this happened, because there will be a WARNING in >>> > /var/log/juju/machine-0.log on the bootstrap machine, like: >>> `failed to >>> > prepare container "0/lxd/0" network config: ...` describing the >>> > underlying error encountered. >>> > >>> > Please note, the above limitation will be gone very soon - likely >>> > beta18, not beta17 scheduled for release this week. In that >>> upcoming >>> > beta, unlinked or unconfigured host machine interfaces won't >>> prevent the >>> > multi-NIC container provisioning and address allocation - Juju >>> will just >>> > allocate addresses where it can, leaving the rest unconfigured, >>> and not >>> > falling back to using LXD default profile's lxdbr0. >>> > >>> > HTH, >>> > Dimiter >>> > >>> > >>> > Hey Dimiter, >>> > >>> > I'm hitting the same issue. I have all the interfaces linked to >>> subnets >>> > with auto but I still get the 'failed to prepare container "0/lxd/0"' >>> > error message saying 'connection is shut down'. The containers are >>> > still using lxdbr0 (see http://paste.ubuntu.com/23188824/ >>> > <http://paste.ubuntu.com/23188824/>). The containers show up on the >>> > nodes page with juju*-lxd-*.maas names. Do you have any other tips for >>> > getting past this? >>> > >>> > Thanks, >>> > Corey >>> >>> >>> -- >>> Dimiter Naydenov <dimiter.nayde...@canonical.com> >>> Juju Core Sapphire team <http://juju.ubuntu.com> >>> >>> >> >> >> -- >> Regards, >> Corey >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju >> >> > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
