> Doing so would require the CPC team to update /etc/default/lxc-net,
setting USE_LXC_BRIDGE to false.
Note that this would cause a conffile prompt for all users using cloud
images who dist-upgrade to pick up the latest updates after another lxc
SRU, which breaks people doing automatic
I've opened bug 1510108 to address 'Stage 2' of this fix.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1509414
Title:
pre-installed lxc in cloud image produces broken lxc (and later
I'm marking this verification-done based on comments:
25 : https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1509414/comments/25
23 : https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1509414/comments/23
21 : https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1509414/comments/21
20 :
This bug was fixed in the package lxc - 1.1.4-0ubuntu1.1
---
lxc (1.1.4-0ubuntu1.1) wily-proposed; urgency=medium
* lxc-net init script: update to select the default lxc bridge network
at first service start time rather than install time. (LP: #1509414)
* lxc-net init
** Description changed:
[Problem]
The released wily image preinstalls lxc, which breaks the assumption that
lxc's preinst packaging script makes:
It inspects the network to try to pick a 10.0.N.0 network that isn't
being used, with N starting at 3, so this appears to have picked
A pre-start lxc hook with sufficient privileges to start lxc-net would
cover all use cases as far as I can tell and would only require the
addition of two files to the lxc package.
Such a hook would also cover LXD as LXD does exec all LXC hooks, so we
wouldn't even have to mess with those init
Such shuffling around as an SRU seems pretty risky to me. Having the
main lxc package be essentially empty except for the systemd postinst
also feels weird.
This would also further complicate things when I then break lxc into lxc
and lxc-common this cycle (lxc-common will include the apparmor
I agree that this shuffling around is not pretty, but we need a solution
that makes 10.0.0.0/16 routable in cloud images where lxc/lxd are not in
use as had prior to http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-
seeds/ubuntu.wily/revision/2360
The current situation conflicts with how
Quoting Stéphane Graber (stgra...@stgraber.org):
> I agree, the stage 2 fix for this issue concerns me with regard to
> regressing current use cases.
>
> As much as I'd like to get rid of the rest of this issue (any user of
> 10.0.4.0/24 behind a router looses connectivity to that subnet), we
Séphane,
When this was added to the cloud seed we changed this from "users that
install LXC will loose connectivity to a 10.0.x.0/24 network" to "all
cloud users do not have connectivity to a 10.0.x.0/24 network at boot"
and the cause/effect will not be as clear to an end user. This had come
up
Kicked off instances for testing with Juju. Will update with results
once my testing is complete.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1509414
Title:
pre-installed lxc in
Cloud images build from proposed are available.
Next action:
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1509414
Title:
pre-installed lxc in cloud image produces broken lxc (and
Cloud image downloads for amd64, i386, and ppc64el are available @ http
://cloud-images.ubuntu.com/proposed/wily/20151024/
The amd64 image is also available in canonistack lcy02 region as
lp1509414/wily-proposed
--
You received this bug notification because you are a member of Ubuntu
Server
Be aware in your testing that the lxd-net's service can come up slowly
depending on the speed of your cloud instance. Without the bridge
(lxcbr0) the container's networking will function prior to that service
starting; watch out for this false positive in your testing.
--
You received this bug
Cloud images build from proposed are available.
Next action:
- Verification of proposed package.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1509414
Title:
pre-installed lxc in
New image works for me in lxc:
lxcbr0Link encap:Ethernet HWaddr 76:79:3e:90:1c:88
inet addr:10.0.4.1 Bcast:0.0.0.0 Mask:255.255.255.0
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
Tested wily-proposed cloud-image running in local kvm. Started wily-
proposed container via lxc (using ubuntu-cloud template), verified the
container's lxcbr0 looks fine (10.0.4.1), verified networking works (via
www.google.com).
--
You received this bug notification because you are a member
I was able to For stage two, at least with systemd, I changed
/lib/systemd/system/lxd-startup.service to:
[Unit]
Description=Container hypervisor based on LXC - boot time check
After=cgmanager.service lxd-unix.socket
Requires=cgmanager.service lxd-unix.socket
[Service]
Type=oneshot
I've also tested manually and via our OpenStack installer and lxcbr0 is
assigned (10.0.4.1) and the network is able to reach out to the internet
as before.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
The lxc in wily-proposed also works for me: inet addr:10.0.4.1
Thanks all.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1509414
Title:
pre-installed lxc in cloud image produces
Verified that Juju can start lxc containers with the proposed changes.
The containers came up and were able to communicate with the state
server, even when on a separate machine.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in
My testing with the cloud image containing the proposed package has been
successful.
Just a note again that the test case detailed in the description is fine
with the understanding that network testing needs to ensure the lxc-net
service has started lxcbr0 or a false positive is possible (per
Serge - your changes from comment #22 will break juju with lxc. juju
will need to be modified to call systemctl add-wants multi-user.target
lxc.service
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
I agree, the stage 2 fix for this issue concerns me with regard to
regressing current use cases.
As much as I'd like to get rid of the rest of this issue (any user of
10.0.4.0/24 behind a router looses connectivity to that subnet), we must
make sure we do not regress anyone who's been relying on
This lxc debdiff (not appropriate upstream lxc) and a pull request
against lxd-pkg-ubuntu (https://github.com/lxc/lxd-pkg-ubuntu/pull/7)
combined should implement stage 2 of the fix.
Note I've tested these when separately implemented by hand, but have not
built packages with this
On Sunday, October 25, 2015 03:12:44 AM you wrote:
> Serge - your changes from comment #22 will break juju with lxc. juju
> will need to be modified to call systemctl add-wants multi-user.target
> lxc.service
If that's the case, this approach for a fix probably isn't appropriate for an
SRU.
--
The cloud-image builder picked up the change and is building images.
They are with the LP buildds now. I will update this bug once
publication completes.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
Hello Mike, or anyone else affected,
Accepted lxc into wily-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/lxc/1.1.4-0ubuntu1.1
in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
** Patch added: "And one more to fix in vms"
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1509414/+attachment/4503681/+files/lxcneta.debdiff
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
Handle one more corner case
** Patch added: "lxcnet9.debdiff"
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1509414/+attachment/4503630/+files/lxcnet9.debdiff
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
** Changed in: lxc (Ubuntu)
Assignee: (unassigned) => Stéphane Graber (stgraber)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1509414
Title:
pre-installed lxc in cloud image
** Summary changed:
- lxc postinst script checks available interfaces, can choose
+ pre-installed lxc in cloud image produces broken lxc (and later lxd)
containers
** Description changed:
[Problem]
The released wily image preinstalls lxc, which breaks the assumption that
lxc's preinst
Action plan:
Stage 1 - Configure lxc-net at boot rather than at install.
* This addresses the network failure for 15.10 containers started on 15.10
hosts (patch above in comment #6)
Stage 2 - Start lxc-net through systemd on the first launch of an LXC container.
* This mitigates the unroutable
Final proposed patch for now. Uploaded to ppa:serge-hallyn/lxc-natty
for wily.
Installing this on a fresh ubuntu-cloud wily container (i.e. a broken
one) results in working lxcbr0 on new subnet.
** Patch added: "lxcnet8.debdiff"
new patch.
It upgrades a broken container fine, but lxc-net is not properly started
until I manually call
/usr/lib/x86_64-linux-gnu/lxc/lxc-net stop
/usr/lib/x86_64-linux-gnu/lxc/lxc-net start
or reboot
** Patch added: "lxcnet6.debdiff"
35 matches
Mail list logo
