On Wed, Sep 24, 2014 at 12:29:53AM -0400, S.Çağlar Onur wrote: > On Wed, Sep 24, 2014 at 12:18 AM, Stéphane Graber <stgra...@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 <stgra...@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.
Ok, then I'll skip it for 1.0.6 and reconsider it for 1.0.7. > > > > > 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; Looks interesting, would be worth sending once we've landed the whole init script rework Mike and I have been working on. I think I'm about done fixing regressions in there and hope to have that pretty big patch up for review tomorrow. > > 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.hal...@ubuntu.com> > >> Date: Fri Aug 22 20:29:23 2014 +0000 > >> > >> Update the openvswitch bridge attach code > >> > >> commit 0d2047716ad6967eb4714b2448a89593dc266cef > >> Author: Serge Hallyn <serge.hal...@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@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@qop:~/Projects/lxc(stable-1.0)] lxc-ls > >> rubik > >> > >> [caglar@qop:~/Projects/lxc(stable-1.0)] lxc-start -d -n rubik > >> > >> [caglar@qop:~/Projects/lxc(stable-1.0)] lxc-attach -n rubik > >> root@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@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@rubik:/# exit > >> > >> [caglar@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@lists.linuxcontainers.org > >> > http://lists.linuxcontainers.org/listinfo/lxc-devel > >> > > >> > >> Cheers > >> -- > >> S.Çağlar Onur <cag...@10ur.org> > >> _______________________________________________ > >> lxc-devel mailing list > >> lxc-devel@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@lists.linuxcontainers.org > > http://lists.linuxcontainers.org/listinfo/lxc-devel > > > > > > -- > S.Çağlar Onur <cag...@10ur.org> > _______________________________________________ > lxc-devel mailing list > lxc-devel@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-devel -- Stéphane Graber Ubuntu developer http://www.ubuntu.com
signature.asc
Description: Digital signature
_______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel