** Changed in: juju-core/1.25
Status: In Progress => Invalid
** Changed in: juju-core/1.25
Importance: Critical => Undecided
** Changed in: juju-core/1.25
Assignee: Dimiter Naydenov (dimitern) => (unassigned)
** Changed in: juju-core/1.25
Milestone: 1.25.7 => None
I got the expected error:
$ juju bootstrap
Bootstrap failed, cleaning up the environment.
ERROR there was an issue examining the environment: failed verification of
local provider prerequisites:
juju-local must be installed to enable the local provider:
sudo apt-get install juju-local
e/1.25
Assignee: Dimiter Naydenov (dimitern) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1590689
Title:
MAAS 1.9.3 + Juju 1.25.5 - on the Juju controller node eth0 and juju-
br0 i
** Package changed: juju-core (Ubuntu) => juju-core
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1592365
Title:
Juju 2.0 crashes on bootstrap with datacentred.co.uk OpenStack cloud
To manage
Filed a separate bug 1584775 for the issue in comment #4
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1584692
Title:
fanatic does not use the user-specified underlay, but 192.168.0.0/16
To manage
Public bug reported:
Something I noticed while trying to use fanatic (see related bug
1584692):
/usr/sbin/fanatic: 808: /usr/sbin/fanatic: lxd-images: not found
Because of this the lxd test cannot spin up the test container, as it can't
import the image.
I managed to get it to work by patching
Another thing I noticed:
/usr/sbin/fanatic: 808: /usr/sbin/fanatic: lxd-images: not found
Because of this the lxd test cannot spin up the test container, as it can't
import the image.
I managed to get it to work by patching fanatic like this:
---
# Check if we have images already...
I wasn't aware I needed to use an underlay range already present on my
machine :/ (I thought it needs a free range to do the config). Using the
defaults (I suspect, 192.168.0.0/16 was auto-detected) worked!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Trying to specify both explicitly yields a different error:
http://paste.ubuntu.com/16630370/
Same result when I run `fanatic configure -u 10.88.0.0/16 -o
250.0.0.0/8` FWIW.
There's a typo in the error message when I at first tried `fanatic -u
10.88.0.0./16 -o 250.0.0.0/8`: Usage:
Public bug reported:
On a xenial machine, I tried to use fanatic to configure the fan with
underlay 10.88.0.0/16 and the suggested overlay 250.0.0.0/8, but the
underlay suggested by fanatic (192.168.0.0/16) was used instead of
10.88.0.0/16 I specified.
Here's the paste of the session:
Additionally, Juju creates bridges on top of both physical and VLAN
interfaces to allow for the same level of addressability for containers
as regular machines. The bridges currently use the "br-" prefix and the
underlying device name, which if it happens to be
"enxxaabbccddeef0.1234" already,
I'm seeing quite a lot of oom kills with multiple boot images imported
in MAAS 2.0.0 (beta3), which depends on tgt via maas-rack-controller
package.
FWIW this issue causes the workaround suggested in bug 1389811
impossible (passing -t 1 to limit the number of threads to 1, rather
than causing oom
Related bug #1520199 fixed in 1.25 and master.
** No longer affects: juju-core
** Changed in: juju-core (Ubuntu)
Status: New => Invalid
** Package changed: juju-core (Ubuntu) => ubuntu
** Package changed: ubuntu => juju-core
** No longer affects: juju-core
--
You received this bug
Related bug #1520199 fixed in 1.25 and master.
** No longer affects: juju-core
** Changed in: juju-core (Ubuntu)
Status: New => Invalid
** Package changed: juju-core (Ubuntu) => ubuntu
** Package changed: ubuntu => juju-core
** No longer affects: juju-core
--
You received this bug
Andres, the issue with b2 is "maas device claim-sticky-ip-
address " (which juju 1.25.1 uses, after creating a device
for the container with parent it's host node) fails to allocate an
address for the device, despite having properly configured ranges and
available IPs.
--
You received this bug
Andres, the issue with b2 is "maas device claim-sticky-ip-
address " (which juju 1.25.1 uses, after creating a device
for the container with parent it's host node) fails to allocate an
address for the device, despite having properly configured ranges and
available IPs.
--
You received this bug
** Changed in: juju-core
Status: Triaged = Incomplete
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
https://bugs.launchpad.net/bugs/1307445
Title:
openstack: instances with multiple nics on the same
** Changed in: juju-core
Status: Triaged = Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1307445
Title:
openstack: instances with multiple nics on the same network don't have
juju-br0 was reintroduced in 1.23.3 as the default behavior in MAAS,
unless the address-allocation feature flag is enabled.
AIUI the juju-br0 swallows the interface-mtu DHCP setting coming
from MAAS. It doesn't happen when eth0 is not bound to juju-br0. So it
looks like this is a pre-existing
Depending on the version of juju used, one option is to set:
lxc-default-mtu: 9000
in environments.yaml for that environment and re-bootstrap. All LXC
containers juju creates should use 9000 as MTU for the eth0 of the
container.
--
You received this bug notification because you are a member of
See also the related bug 1442257 which has a proposed fix.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
https://bugs.launchpad.net/bugs/1355813
Title:
Interface MTU management across MAAS/juju
To manage
See also the related bug 1442257 which has a proposed fix.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1355813
Title:
Interface MTU management across MAAS/juju
To manage notifications about this
Since 1.23 there's no need to create juju-br0 (or as it used to be
called before - br0) at initial boot, so this should solve the issue.
** Changed in: juju-core
Status: Triaged = Fix Committed
** Changed in: juju-core
Milestone: None = 1.23-beta1
--
You received this bug
Blake, yes that's correct - having stable names based on udev rules,
especially discoverable via the API will be the proper way to fix this
for MAAS. The solution proposed in comment #1 could potentially work for
any provider, but relying on networking features (discovery,
configuration, even
Blake, yes that's correct - having stable names based on udev rules,
especially discoverable via the API will be the proper way to fix this
for MAAS. The solution proposed in comment #1 could potentially work for
any provider, but relying on networking features (discovery,
configuration, even
** Tags added: network
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1307445
Title:
openstack: instances with multiple nics on the same network don't have
deterministic private-addresses
To
** Tags added: network
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
https://bugs.launchpad.net/bugs/1307445
Title:
openstack: instances with multiple nics on the same network don't have
deterministic
There's an updated gccgo-go version for vivid -
https://launchpad.net/ubuntu/+source/gccgo-go/1.2.1-0ubuntu7 which
includes fixes for a number of issues we're seeing (tests failing,
builds failing due to duplicate symbols, random instabilities). Why is
this 1.2.1-0ubuntu7 not backported to trusty
It turns out the vivid package does not yet have the needed patch from
https://go-review.googlesource.com/#/c/1840/ we'll have to wait for an
upstream release I guess.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
It turns out the vivid package does not yet have the needed patch from
https://go-review.googlesource.com/#/c/1840/ we'll have to wait for an
upstream release I guess.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
It turns out the vivid package does not yet have the needed patch from
https://go-review.googlesource.com/#/c/1840/ we'll have to wait for an
upstream release I guess.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Related bug 1417771. Let's release an updated version of gccgo-go for
trusty at least, if not precise. In vivid, a more recent release
(1.2.1-0ubuntu7 ) has the fix.
** Changed in: gccgo-go (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of
Related bug 1417771. Let's release an updated version of gccgo-go for
trusty at least, if not precise. In vivid, a more recent release
(1.2.1-0ubuntu7 ) has the fix.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
OK, jamespage confirmed a port to precise is not happening, as there's
no ppc64 support in there. That's fine - let's see what we can do for
trusty though.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
The problem in such cases is juju has little control on how the
machine's hardware (as seed by lshw) changes between commissioning and
deployment, and frankly neither has maas.
jamespage suggested that juju could inject a script very early (e.g. a
bootcmd) in the cloud-init userdata to try and
The problem in such cases is juju has little control on how the
machine's hardware (as seed by lshw) changes between commissioning and
deployment, and frankly neither has maas.
jamespage suggested that juju could inject a script very early (e.g. a
bootcmd) in the cloud-init userdata to try and
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
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
I think we can close this now - juju status --format accepts a number of
new output formats (in addition to the default yaml and optional
json). Excerpt from juju status --help:
There are a number of ways to format the status output:
- {short|line|oneline}: List units and their subordinates. For
I think we can close this now - juju status --format accepts a number of
new output formats (in addition to the default yaml and optional
json). Excerpt from juju status --help:
There are a number of ways to format the status output:
- {short|line|oneline}: List units and their subordinates. For
Proposed a fix with http://reviews.vapour.ws/r/686/ - before starting a
container, the host's primary physical NIC's MTU value is detected and
applied to the container's veth device.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to
** 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/1355813
Title:
Interface MTU management across MAAS/juju
To manage notifications
Proposed a fix with http://reviews.vapour.ws/r/686/ - before starting a
container, the host's primary physical NIC's MTU value is detected and
applied to the container's veth device.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Changed in: juju-core
Status: In Progress = Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
https://bugs.launchpad.net/bugs/1355813
Title:
Interface MTU management across MAAS/juju
To
** Changed in: juju-core
Assignee: (unassigned) = Dimiter Naydenov (dimitern)
** 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/1355813
** Changed in: juju-core
Assignee: (unassigned) = Dimiter Naydenov (dimitern)
** Changed in: juju-core
Status: Triaged = In Progress
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
https
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
Server Team, which is subscribed to juju-core in Ubuntu.
https://bugs.launchpad.net/bugs/1271144
Title:
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
@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: root=TRACE to your maas
@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
Server Team, which is subscribed to juju-core in Ubuntu.
https://bugs.launchpad.net/bugs/1271144
Title:
br0 not brought up
@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
@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:
root=TRACE for your maas environment.
2. Run $ juju bootstrap --debug ~/maas-bootstrap.log
3. Once the machine is up and you can
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
@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: root=TRACE to your maas
@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
@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
@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:
root=TRACE for your maas environment.
2. Run $ juju bootstrap --debug ~/maas-bootstrap.log
3. Once the machine is up and you can
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
*** This bug is a duplicate of bug 1338673 ***
https://bugs.launchpad.net/bugs/1338673
Public bug reported:
I've already reported this several times, as it happens multiple times
after login or later.
ProblemType: Crash
DistroRelease: Ubuntu 14.10
Package: xserver-xorg-video-intel
Public bug reported:
Occurs 5 times after login each time.
ProblemType: Crash
DistroRelease: Ubuntu 14.10
Package: xserver-xorg-video-intel 2:2.99.910-0ubuntu1
ProcVersionSignature: Ubuntu 3.15.0-6.11-generic 3.15.0
Uname: Linux 3.15.0-6-generic x86_64
NonfreeKernelModules: wl
Public bug reported:
I get the crash report dialog after every login, often more than one.
ProblemType: Crash
DistroRelease: Ubuntu 14.10
Package: xserver-xorg-video-intel 2:2.99.910-0ubuntu1
ProcVersionSignature: Ubuntu 3.15.0-6.11-generic 3.15.0
Uname: Linux 3.15.0-6-generic x86_64
How is this a regression in juju-core when the issue seems to be the
slower updating of streams.canonical.com after the release? This is
bound to happen at any time we do a release and update streams.c.c some
time after.
--
You received this bug notification because you are a member of Ubuntu
How is this a regression in juju-core when the issue seems to be the
slower updating of streams.canonical.com after the release? This is
bound to happen at any time we do a release and update streams.c.c some
time after.
--
You received this bug notification because you are a member of Ubuntu
Public bug reported:
I'm using a native repo in ~/src/juju-core. I have a lightweight checkout of it
in ~/go/src/launchpad.net/juju-core/ (in my $GOPATH).
In addition I have a symlink in ~/work/juju-core pointing to the second path
above.
I have 2 branches: trunk and 041-provisioner-api-calls
Thanks for investigating this! You can find plan9port and installation
instructions from here: http://swtch.com/plan9port/
I forgot to mention, in order to build p9p I also installed wget and
build-essential into the container.
--
You received this bug notification because you are a member of
So I followed your suggestions for retracing he apport dump and got
these results (not much I'm afraid): http://paste.ubuntu.com/5645895/
(1st option); http://paste.ubuntu.com/5645890/ (2nd option).
I'll try replicating the same steps I did before from scratch to see if
I can reproduce it later
Thanks for investigating this! You can find plan9port and installation
instructions from here: http://swtch.com/plan9port/
I forgot to mention, in order to build p9p I also installed wget and
build-essential into the container.
--
You received this bug notification because you are a member of
So I followed your suggestions for retracing he apport dump and got
these results (not much I'm afraid): http://paste.ubuntu.com/5645895/
(1st option); http://paste.ubuntu.com/5645890/ (2nd option).
I'll try replicating the same steps I did before from scratch to see if
I can reproduce it later
Public bug reported:
I created a container with lxc-create -t ubuntu -n test1; started it (lxc-start
-n test1); installed plan9port and some x-related packages (xterm, xdm,
xserver-xorg-core, xserver-xorg). Then, while it was still running, logged out
and run lxc-destroy -n test1, which hung
Public bug reported:
I created a container with lxc-create -t ubuntu -n test1; started it (lxc-start
-n test1); installed plan9port and some x-related packages (xterm, xdm,
xserver-xorg-core, xserver-xorg). Then, while it was still running, logged out
and run lxc-destroy -n test1, which hung
Public bug reported:
It's really frustrating that every time the update manager runs and
applies an update, my keyboard shortcut for showing the HUD (default:
Alt L) is reset to the default and I always have to set it back to
something else (which I never use, like Shift+Ctrl+Alt+F12). I do this,
** Attachment added: transmission-2.jpg
https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/1129159/+attachment/3534868/+files/transmission-2.jpg
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Public bug reported:
This is really, just a minor, trivial thing.
When you open the app indicator menu for Transmission, and click Show
Transmission, the checkbox gets updated and the main window shows (or
hides if it was visible). Now, if you close the window and open it from
the Launcher
** Attachment added: transmission-3.jpg
https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/1129159/+attachment/3534869/+files/transmission-3.jpg
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Branch linked: lp:~jameinel/maas/1.2-node-get-effective-kernel-
options
** Branch linked: lp:~gz/maas/1.2_add_db_kernel_params
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1044503
** Branch linked: lp:~jameinel/maas/1.2-node-get-effective-kernel-
options
** Branch linked: lp:~gz/maas/1.2_add_db_kernel_params
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1044503
Title:
** Branch linked: lp:~dimitern/maas/1.2-node-view-shows-kernel-params
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1044503
Title:
kernel command line is not easily customizable
To
Public bug reported:
I'm using a VM, running 12.10, upgraded from 12.04.1 (server). Using a
bzr checkout dir on the VM and mounting that locally on the host with
SSH from /home/USER/.gvfs/home/VMUSER/work/maas, symlinked to
/home/USER/work/maas, then running bzr branch --switch on the host,
while
** Summary changed:
- bzr branch fails on a ssh mount of remove ext4 fs with Error 95 Operation Not
Supported
+ bzr branch fails on a ssh mount of remote ext4 fs with Error 95 Operation Not
Supported
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
** Branch linked: lp:~dimitern/maas/1.2-node-view-shows-kernel-params
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1044503
Title:
kernel command line is not easily customizable
To manage
** Changed in: maas
Status: In Progress = Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/994887
Title:
Nodes listing does not support sorting
To manage
** Changed in: maas
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/994887
Title:
Nodes listing does not support sorting
To manage notifications about this
** Branch linked: lp:~dimitern/maas/bug-994887-alternate-nodes-list-
sorting
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/994887
Title:
Nodes listing does not support sorting
To
** Branch linked: lp:~dimitern/maas/bug-994887-alternate-nodes-list-
sorting
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/994887
Title:
Nodes listing does not support sorting
To manage
** Changed in: maas
Status: Triaged = In Progress
** Changed in: maas
Assignee: (unassigned) = Dimiter Naydenov (dimitern)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs
** Branch linked: lp:~dimitern/maas/bug-994887-nodes-listing-does-not-
support-sorting
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/994887
Title:
Nodes listing does not support
** Changed in: maas
Status: Triaged = In Progress
** Changed in: maas
Assignee: (unassigned) = Dimiter Naydenov (dimitern)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/994887
Title
** Branch linked: lp:~dimitern/maas/bug-994887-nodes-listing-does-not-
support-sorting
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/994887
Title:
Nodes listing does not support sorting
To manage
88 matches
Mail list logo
