This issue was fixed when trusty-updates got 1.22.6.
** Changed in: juju-core (Ubuntu Trusty)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1271144
Title:
Which version of juju are you using? What's the content of the lshw xml
dump for the instance with the p1p1 NIC? The MAAS provider uses that
lshw output generated during the node's commissioning to determine which
is the primary NIC on that node, so it can be added into the bridge.
--
You receive
hits me when doing an openstack autopilot install with MAAS and juju
trying to work eth0 into the juju-br0 bridge.
but i have p1p1.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1271144
Title:
br0
i am using Ubuntu 14.10 LDS (landscape local server) and 14.04 as target
on the machines bootstrapped by a 14.04 MAAS.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1271144
Title:
br0 not brought up
** Branch linked: lp:~ubuntu-cloud-archive/ubuntu/precise/juju-core
/precise-ctools
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1271144
Title:
br0 not brought up by cloud-init script with MAAS pro
/etc/network/interfaces
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet manual
auto juju-br0
iface juju-br0 inet dhcp
bridge_ports eth0
/etc/network/interfaces.d is empty
--
You received this bug notification beca
Yes, it appears you're having a separate issue. I'd appreciate if you
open a new bug for it and we can continue there.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1271144
Title:
br0 not brought up
I simply issued "sudo reboot" and this happened. So I assume then that
I have a different issue from the original reporter? Should I open a
separate bug and stop polluting this one?
In the meantime I'll pull the requested config files.
--
You received this bug notification because you are a me
Thanks for the logs! None of them show anything alarming.
However something is wrong with your setup. How did you reboot the instance
after the bootstrap was done? Once MAAS provisions a machine cloud-init should
not run anymore - it's only used to boot the initial OS. Did you recommission
or de
And lastly the logs from the node after it is rebooted. On this boot it
takes a very long time to come up as cloud-init waits for the network
bridge to come up and then eventually errors out.
** Attachment added: "logs2.zip"
https://bugs.launchpad.net/juju-core/+bug/1271144/+attachment/428223
Here is the bootstrap log created when I run "juju bootstrap --to
db2.ed1.mavennetwork.co.uk --debug &> ~/maas-bootstrap.log"
** Attachment added: "maas-bootstrap.log"
https://bugs.launchpad.net/juju-core/+bug/1271144/+attachment/4282230/+files/maas-bootstrap.log
--
You received this bug not
And these are the juju and cloud logs from the node which was
bootstrapped. This node is working fine right now but once it is
rebooted I will get the cloud-init problem. I'll reboot it now and then
post the logs after the problematic boot.
** Attachment added: "logs.zip"
https://bugs.launch
@mark-dickie: Ok, 1.21-beta3 actually should have the fix - no need to
build from source. Can you:
1. Edit your ~/.juju/environments.yaml to include "logging-config:
=TRACE" for your maas environment.
2. Run $ juju bootstrap --debug &> ~/maas-bootstrap.log
3. Once the machine is up and you can SS
@dimitern
Quite right, it is the devel branch I'm using. I was trying to find a
new version which might already have a fix. I'm not very up on building
software based on go. I'm getting the following when I try to run "go
install -v launchpad.net/juju-core/..."
go build launchpad.net/juju-core
@mark-dickie - I can't see 1.21-beta3 in
https://launchpad.net/~juju/+archive/ubuntu/proposed are you sure you
didn't mean https://launchpad.net/~juju/+archive/ubuntu/devel ?
Thanks for sharing the workaround - at least it gives me something to
look into! :)
--
You received this bug notificatio
Also I've found that if I edit /etc/init/networking.conf and change the
starts on line to:-
starts on stopped cloud-init-local
Then everything works fine although I realise that this is a very poor
solution. Best I could manage with my limited upstart knowledge.
--
You received this bug notifi
@dimitern Thanks for the swift reply. I'll do this now, for your
information I'm currently running juju 1.21-beta3-trusty-amd64 from the
juju-proposed ppa.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bug
@mwenning - What's the output of $ juju version? Can you try what I've
proposed in comment #46?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1271144
Title:
br0 not brought up by cloud-init script w
@mark-dickie Can you please try to reproduce this with the latest juju-
core built from source (master branch) to see if you still have an
issue? If you do, please attach the following logs to help us analyze
the issue better:
Before anything, please add "logging-config: =TRACE" to your maas
envi
Same as comment #44 I'm running hardware MAAS and I get this on every
deployment. If I let cloud-init error out I can get logged in and juju-
br0 is up by that point but it doesn't come up until after cloud-init
tries to do it's stuff. This makes the nodes I deploy unusable.
I'm going to see if
I'm seeing the same error on my hardware MAAS cluster with the latest
maas stable and juju stable . Failing bridge on the bootstrap node is
called "juju-br0". I will post more info on Monday.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
I've found a workaround for the issue to let me launch lxc containers
via juju
After the first container fails to launch, ssh to the hypervisor
edit /var/lib/lxc/juju-trusty-lxc-template/config
change br0 -> lxcbr0
After editing the template config all subsequent lxc containers will
launch via ju
Using 14.04, MAAS in a KVM, and Juju in a KVM. Same issue that lxe
container launches with br0 instead of lxcvr0
juju status -> https://pastebin.canonical.com/119755/
Unable to find failed container log output
juju machine agent log -> https://pastebin.canonical.com/119746/
cloudinit log -> https:
on machine 0 (orangebox kvm maas instance)
the ifconfig output is https://pastebin.canonical.com/119756/
the lxc conf is https://pastebin.canonical.com/119757/
the container there also failed to start.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subs
just got a report of the same issue and resolution with 1.20.11 on
orangebox maas. same s/br0/lxcbr0 fix for the container on machine 0. we
tried again and got a slightly different issue on machine 2's container
Forensenic
status output -> https://pastebin.canonical.com/119751/
failed container l
** Tags added: cts
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1271144
Title:
br0 not brought up by cloud-init script with MAAS provider
To manage notifications about this bug go to:
https://bugs
@danieru: what network interfaces show up? is the primary network
interface called something other than "eth0"? If so, you'd need to set
the "network-bridge" attribute in environments.yaml.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubunt
Hi,
I'm seeing this problem in juju-core/1.20.5.
During 'juju bootstrap' it finally fails with:
"ERROR bootstrap failed: waited for 10m0s without being able to connect:
ssh: connect to host 192.168.122.105 port 22: No route to host"
And on the guest console it complains that br0 not brought up
** No longer affects: juju-core/1.20
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1271144
Title:
br0 not brought up by cloud-init script with MAAS provider
To manage notifications about this bug g
** Also affects: juju-core/1.20
Importance: Undecided
Status: New
** Changed in: juju-core/1.20
Milestone: None => 1.20.2
** Changed in: juju-core/1.20
Importance: Undecided => High
** Changed in: juju-core/1.20
Status: New => Triaged
--
You received this bug notificati
Sorry, I was thinking that lp:1337091 was released already. We will look
at getting it into 1.20.2.
If you set the kernel parameter via MAAS [0] prior to first boot, then I
would concur that it's probably not going to help. If, however, you
modified GRUB after it came up and rebooted, I think that
1.20.1 is in the juju stable ppa:
sudo add-apt-repository ppa:juju/stable
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1271144
Title:
br0 not brought up by cloud-init script with MAAS provider
To
Thanks for the reply. I'm willing to try anything that is recommended.
The primary NIC on Trusty come up as em1, not eth0. Therefore, I've been
assuming that the fix for #1337091 will, at least, be required to
address this issue. Whether it will be sufficient is an open question,
but I'm skeptical
Rick,
Sorry for the frustration. It is certainly not unreasonable to expect
14.04 to be working.
br0 is only brought up on first boot, so rebooting would not have
triggered that part of cloud-config again.
I believe we are looking at back-porting Juju 1.20.2 (the next stable
release) into 14.04.
There has been a lot of activity on this bug with more than one issue
involved and so I just wanted to confirm:
This problem still exists with maas 1.5.2+bzr2282 and juju 1.18.1 (the
current stable releases) when you bootstrap a node with trusty.
Therefore, it breaks Canonical's OpenStack "Golden
** Tags added: canonical-is
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1271144
Title:
br0 not brought up by cloud-init script with MAAS provider
To manage notifications about this bug go to:
htt
Hello @ivoks, @shivrao,
I opened the bug LP:#1337091 for addressing the problem of juju trying
to bring a new bridge with an inteface != eth0, inteface should be
configurable via the network-bridge configuration directive.
--
You received this bug notification because you are a member of Ubuntu
Sorry forgot to mention this: The management interface on this bootstrap
node is eth2. And as reported earlier in the thread by Ante, br0 is not
being created.
Some more info:
And i am using fast-path installer for this node.
MAAS version: 1.5.1+bzr2269-0ubuntu0.1
--
You received this bug notif
We are deploying lxc to bootstrap daily, using 1.5.1+bzr2269-0ubuntu0.1
from trusty-updates. Which one are you using?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1271144
Title:
br0 not brought up
Confirming this issue on trusty with juju 1.19.4 and maas 1.5.1
cloud-init still creates eth0.config:
iface eth0 inet manual
auto br0
iface br0 inet dhcp
bridge_ports eth0
And this is how it looks in /etc/network/interfaces:
# The loopback network interface
auto lo
iface lo inet loopback
> So, my nodes don't have eth0, but p1p1, if that makes any difference.
This is most likely the key; the MAAS provider code assumes it's dealing
with eth0. Thanks for the information.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
ht
So, my nodes don't have eth0, but p1p1, if that makes any difference.
I've noticed that br0 was not configured, so I manually added it to
/etc/network/interfaces. After I brought up the interface, I've deployed
a charm within LXC container.
Nodes are deployed by MAAS.
So, obviously, this is still
Confirming this issue on trusty with juju 1.18.4. br0 is not created.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1271144
Title:
br0 not brought up by cloud-init script with MAAS provider
To mana
Forgot to include that detail. Trusty
Sent from my iPhone
> On Apr 25, 2014, at 2:58 PM, Andreas Hasenack wrote:
>
> As a counterpoint, it worked for me with juju 1.18.1:
>
> $ juju status
> environment: scapestack
> machines:
> "0":
>agent-state: started
>agent-version: 1.18.1
>d
As a counterpoint, it worked for me with juju 1.18.1:
$ juju status
environment: scapestack
machines:
"0":
agent-state: started
agent-version: 1.18.1
dns-name: some.node
instance-id: /MAAS/api/1.0/nodes/node-some-uuid
series: precise
services: {}
$ juju ssh 0 ifconfig br0
br
This appears to be happening again on juju-core 1.18.1. When I attempted
to create a new lxc container on the bootstrapped node (machine: 0), I
received a lxc-start error. After reviewing this bug report, I manually
added in the br0 interface into /etc/network/interfaces and ran ifup
br0. Followin
This bug was fixed in the package juju-core - 1.17.6-0ubuntu1
---
juju-core (1.17.6-0ubuntu1) trusty; urgency=medium
* New upstream point release, including fixes for:
- br0 not bought up by cloud-init with MAAS provider (LP: #1271144).
- ppc64el enablement for juju/lxc (LP:
** Changed in: juju-core
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1271144
Title:
br0 not brought up by cloud-init script with MAAS provider
To mana
The reason why the test in comment 8 was passing but we were still
seeing errors is that the APT index was up to date for Wayne, but not
for us - debootstrap vs. fastpath installer.
This might be worth noting for any future MAAS bugs, to be sure to test
it in both scenarios.
--
You received this
** Branch linked: lp:~axwalk/juju-core/lp1271144-maas-bridge-utils
** Changed in: juju-core
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1271144
Title:
** Changed in: juju-core
Assignee: Roger Peppe (rogpeppe) => Andrew Wilkins (axwalk)
** Changed in: juju-core
Status: Triaged => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1
Can someone please test this?
lp:~thumper/juju-core/maas-no-restart-networking
I don't have a MAAS setup to hand, but according to the code above, this
*should* work.
Now we go
ifdown eth0
before messing with the network config, and
ifup eth0
ifup br0
after, and no 'restart ne
hazmat: remember the br0 not coming up bug on the bootstrap node?
There were two cloud-init configs involved, right? Because br0 does get up in
services deployed to new machines, just not in the bootstrap one
hinting that the one used for bootstrap is different than the rest
there was a long d
I applied this patch and it worked:
=== modified file 'provider/maas/environ.go'
--- provider/maas/environ.gorevid:tarmac-20140314141156-nsn5oeamfi31t1ct
+++ provider/maas/environ.go2014-03-19 16:54:28 +
@@ -266,7 +266,13 @@
userdata, err := environs.ComposeUserData(
Confirming (again) - seen with 1.17.5 on trusty - bootstrap node does
not have bridge networking.
Raising distro task for tracking.
** Also affects: juju-core (Ubuntu)
Importance: Undecided
Status: New
** Changed in: juju-core (Ubuntu)
Importance: Undecided => Critical
** Also affe
55 matches
Mail list logo