[lxc-devel] Planning for LXC 1.0.6 to be released on Wednesday
S.Çağlar Onur
caglar at 10ur.org
Wed Sep 24 04:29:53 UTC 2014
On Wed, Sep 24, 2014 at 12:18 AM, Stéphane Graber <stgraber at ubuntu.com> wrote:
> On Wed, Sep 24, 2014 at 12:10:16AM -0400, S.Çağlar Onur wrote:
>> Hey Stéphane,
>>
>> On Tue, Sep 23, 2014 at 12:21 AM, Stéphane Graber <stgraber at ubuntu.com> wrote:
>> > Hey everyone,
>> >
>> > So I've finally caught up on all the master patches and pushed
>> > everything to the stable-1.0 branch. All tests pass on all architectures
>> > and a tiny bit of manual testing didn't find any obvious problem with
>> > it.
>> >
>> > As a result, I'm planning on tagging 1.0.6 on Wednesday unless we find
>> > any major issue by then.
>> >
>> >
>> > Also, I believe I've cherry-picked all the master changes which aren't a
>> > new feature or related to a new feature, but if there's something in
>> > master which you absolutely need in stable and it's not in the list of
>> > commits I've cherry-picked, please get in touch!
>>
>> Would it be possible to cherry-pick following two openvswitch related
>> patch in to the stable tree? As long as I see these should be harmless
>> for stable.
>
> I'll have to think about it. OVS support is one of those changes that's
> a bit borderline between a bugfix (supporting all bridge and interface
> types) and a new feature and so far I've put it in the latter category
> which excludes it for stable releases.
Totally understand your stance.
> What's your usecase for it? I believe the driving force behind adding
> OVS support to LXC was to support the development of an OpenStack driver
> which required it, but that driver I believe requires LXC 1.1 for other
> features (qcow2 support), so I'm interested in knowing about other
> usecases.
To be honest I really don't have any real use case. I recently started
play with openvswitch to prototype something and for that reason I can
easily keep those commits in my local tree. I just thought it could be
helpful for the others as googling "lxc openvswitch" shows lots of
different (sometimes really complex) ways to achieve what those two
commits provides.
>
> Also, there's a third commit which we'd have to cherry-pick in order to
> fix the security bug introduced by the first two. That's the one adding
> a call to clearenv() to ensure that all the environment is clean before
> we start execing commands from a setuid binary.
Yep, I had that in my local tree but forgot to mention, thanks for
catching it! I also have following and I could submit if you think
that's something you may want;
diff --git a/config/init/upstart/lxc-net.conf b/config/init/upstart/lxc-net.conf
index 279cd1e..5848824 100644
--- a/config/init/upstart/lxc-net.conf
+++ b/config/init/upstart/lxc-net.conf
@@ -5,6 +5,7 @@ start on starting lxc
stop on stopped lxc
env USE_LXC_BRIDGE="true"
+env USE_OPENVSWITCH="false"
env LXC_BRIDGE="lxcbr0"
env LXC_ADDR="10.0.3.1"
env LXC_NETMASK="255.255.255.0"
@@ -33,7 +34,11 @@ pre-start script
iptables $use_iptables_lock -t nat -D POSTROUTING -s
${LXC_NETWORK} ! -d ${LXC_NETWORK} -j MASQUERADE || true
iptables $use_iptables_lock -t mangle -D POSTROUTING
-o ${LXC_BRIDGE} -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
ifconfig ${LXC_BRIDGE} down || true
- brctl delbr ${LXC_BRIDGE} || true
+ if [ "x$USE_OPENVSWITCH" = "xtrue" ]; then
+ ovs-vsctl --if-exists del-br ${LXC_BRIDGE} || true
+ else
+ brctl delbr ${LXC_BRIDGE} || true
+ fi
}
if [ -d /sys/class/net/${LXC_BRIDGE} ]; then
@@ -45,7 +50,11 @@ pre-start script
fi
# set up the lxc network
- brctl addbr ${LXC_BRIDGE} || { echo "Missing bridge support in
kernel"; stop; exit 0; }
+ if [ "x$USE_OPENVSWITCH" = "xtrue" ]; then
+ ovs-vsctl --may-exist add-br ${LXC_BRIDGE} || { echo
"Missing bridge support in kernel"; stop; exit 0; }
+ else
+ brctl addbr ${LXC_BRIDGE} || { echo "Missing bridge
support in kernel"; stop; exit 0; }
+ fi
echo 1 > /proc/sys/net/ipv4/ip_forward
mkdir -p ${varrun}
ifconfig ${LXC_BRIDGE} ${LXC_ADDR} netmask ${LXC_NETMASK} up
@@ -86,7 +95,11 @@ post-stop script
iptables $use_iptables_lock -t mangle -D POSTROUTING
-o ${LXC_BRIDGE} -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
pid=`cat ${varrun}/dnsmasq.pid 2>/dev/null` && kill -9
$pid || true
rm -f ${varrun}/dnsmasq.pid
- brctl delbr ${LXC_BRIDGE}
+ if [ "x$USE_OPENVSWITCH" = "xtrue" ]; then
+ ovs-vsctl --if-exists del-br ${LXC_BRIDGE} || true
+ else
+ brctl delbr ${LXC_BRIDGE} || true
+ fi
fi
rm -f ${varrun}/network_up
end script
>>
>> commit 6ad22d063aa0fdbd77425acd7f9c9de79e5aff3e
>> Author: Serge Hallyn <serge.hallyn at ubuntu.com>
>> Date: Fri Aug 22 20:29:23 2014 +0000
>>
>> Update the openvswitch bridge attach code
>>
>> commit 0d2047716ad6967eb4714b2448a89593dc266cef
>> Author: Serge Hallyn <serge.hallyn at ubuntu.com>
>> Date: Mon Jul 21 17:48:55 2014 -0500
>>
>> Support openvswitch bridges
>>
>> the only change I needed to make was following
>>
>> diff --git a/src/lxc/network.c b/src/lxc/network.c
>> index b01297c..bdd1882 100644
>> --- a/src/lxc/network.c
>> +++ b/src/lxc/network.c
>> @@ -1187,7 +1187,7 @@ static int attach_to_ovs_bridge(const char
>> *bridge, const char *nic)
>> pid_t pid;
>> char *cmd;
>>
>> - cmd = on_path("ovs-vsctl", NULL);
>> + cmd = on_path("ovs-vsctl");
>> if (!cmd)
>> return -1;
>> free(cmd);
>>
>> After converting lxcbr0 to openvswitch bridge everything seems to be
>> working as expected (except veths do not appear to be removed from the
>> openvswitch bridge as Serge pointed in his commit message)
>>
>> [caglar at qop:~/Projects/lxc(stable-1.0)] sudo ovs-vsctl show
>> 7170a597-4680-4e7b-ade4-2df164b2f397
>> Bridge "lxcbr0"
>> Port "lxcbr0"
>> Interface "lxcbr0"
>> type: internal
>> ovs_version: "2.0.2"
>>
>> [caglar at qop:~/Projects/lxc(stable-1.0)] lxc-ls
>> rubik
>>
>> [caglar at qop:~/Projects/lxc(stable-1.0)] lxc-start -d -n rubik
>>
>> [caglar at qop:~/Projects/lxc(stable-1.0)] lxc-attach -n rubik
>> root at rubik:/# ifconfig
>> eth0 Link encap:Ethernet HWaddr ae:0c:ee:29:47:80
>> inet addr:10.0.3.7 Bcast:10.0.3.255 Mask:255.255.255.0
>> inet6 addr: fe80::ac0c:eeff:fe29:4780/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:38 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:20 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:5534 (5.5 KB) TX bytes:2376 (2.3 KB)
>>
>> lo Link encap:Local Loopback
>> inet addr:127.0.0.1 Mask:255.0.0.0
>> inet6 addr: ::1/128 Scope:Host
>> UP LOOPBACK RUNNING MTU:65536 Metric:1
>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:0
>> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
>>
>> root at rubik:/# ping www.google.com
>> PING www.google.com (64.233.181.147) 56(84) bytes of data.
>> 64 bytes from 64.233.181.147: icmp_seq=1 ttl=61 time=58.3 ms
>> 64 bytes from 64.233.181.147: icmp_seq=2 ttl=61 time=59.8 ms
>> ^C
>> --- www.google.com ping statistics ---
>> 2 packets transmitted, 2 received, 0% packet loss, time 1002ms
>> rtt min/avg/max/mdev = 58.382/59.108/59.835/0.766 ms
>> root at rubik:/# exit
>>
>> [caglar at qop:~/Projects/lxc(stable-1.0)] sudo ovs-vsctl show
>> 7170a597-4680-4e7b-ade4-2df164b2f397
>> Bridge "lxcbr0"
>> Port "vethUGPWF2"
>> Interface "vethUGPWF2"
>> Port "lxcbr0"
>> Interface "lxcbr0"
>> type: internal
>> ovs_version: "2.0.2"
>>
>> > --
>> > Stéphane Graber
>> > Ubuntu developer
>> > http://www.ubuntu.com
>> >
>> > _______________________________________________
>> > lxc-devel mailing list
>> > lxc-devel at lists.linuxcontainers.org
>> > http://lists.linuxcontainers.org/listinfo/lxc-devel
>> >
>>
>> Cheers
>> --
>> S.Çağlar Onur <caglar at 10ur.org>
>> _______________________________________________
>> lxc-devel mailing list
>> lxc-devel at lists.linuxcontainers.org
>> http://lists.linuxcontainers.org/listinfo/lxc-devel
>
> --
> Stéphane Graber
> Ubuntu developer
> http://www.ubuntu.com
>
> _______________________________________________
> lxc-devel mailing list
> lxc-devel at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel
>
--
S.Çağlar Onur <caglar at 10ur.org>
More information about the lxc-devel
mailing list