If would be great to have an ebuild for openvswitch (http://openvswitch.org/) in portage. Quite cool and supports the most popular virtualization technologies. Reproducible: Always
Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manner. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Thanks, On behalf of the Gentoo Sunrise Team, Michael. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
ok first, lots of information is given here http://openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_plain;f=INSTALL.Linux;hb=HEAD
Created attachment 282907 [details] first try of openvswitch ebuild
Created attachment 283171 [details] net-misc/openvswitch/openvswitch-1.2.0.ebuild More sophisticated ebuild
Created attachment 283173 [details] net-misc/openvswitch/files/ovsdb-server init-script for db-server
Created attachment 283177 [details] net-misc/openvswitch/files/ovs-vswitchd init-script for ovs-vswitchd
Created attachment 283179 [details] net-misc/openvswitch/files/ovsdb-server_conf Service configuration for ovsdb-server
Created attachment 283181 [details] net-misc/openvswitch/files/ovs-vswitchd_conf Service configuration for ovs-vswitchd
Would be nice if someone with more ebuild experience could review this
as a side-node: I've added the init.d-scripts to my version of the ebuild in my dev-overlay. I hope I can look at them again and then move the ebuild to the tree.
The ebuild works fine by renaming for 1.3.0 => just bumpp
Created attachment 300669 [details] net-misc/openvswitch/openvswitch-1.4.0.ebuild updated open-vswitch ebuild, need to add test/hint for inkernel datapath when using >=linux-3.3
Created attachment 300671 [details] net-misc/openvswitch/openvswitch-9999.ebuild live ebuild for openvswitch, need to add test/hint for inkernel datapath when using >=linux-3.3
I'm currently working on patches for xen adding openvswitch support, I'll attach them tomorrow, they are working most of the way, just rmeoving the hvm-qemu tap interfaces fails for some reason, maybe I have time to dig into it (hint have a look for epatch_user to add this in a comfortable way). Additionally I started adding kernel-3.3 support, it works but I guess I somehow missusing the linux_info eclass
Created attachment 305983 [details] net-misc/openvswitch/openvswitch-1.4.0-r1.ebuild see comment above ;)
(In reply to comment #10) > as a side-node: I've added the init.d-scripts to my version of the ebuild in > my dev-overlay. I hope I can look at them again and then move the ebuild to > the tree. If I get it tomorrow. I'll merge my stuff with yours, to get to a common base.
Created attachment 306033 [details] net-misc/openvswitch/openvswitch-1.4.0-r2.ebuild Added patched ebuild based on your work. Changes: * use python eclass and depend on python:2 since parts of openvswitch are not yet compatible to python:3 * add tcpdump as configurable runtime dependency (see README) * add support for brcompat module (bridge compatibility layer) and related init script * changed socket path from /var/lib/run/openvswitch to /var/run/openvswitch Works fine with Xen 4.1.2 and vanilla kernel 3.2.5. Ebuilds for openvswitch [1] and xen-tools [2] can be found in our little overlay. I should have filed bugs, I know...
Created attachment 306035 [details] net-misc/openvswitch/files/ovs-brcompatd
Ah, forgot to append links ;) [1] http://subversion.fem.tu-ilmenau.de/repository/fem-overlay/trunk/net-misc/openvswitch/ [2] http://subversion.fem.tu-ilmenau.de/repository/fem-overlay/trunk/app-emulation/xen-tools/
(In reply to comment #17) > Created attachment 306033 [details] > net-misc/openvswitch/openvswitch-1.4.0-r2.ebuild > > Added patched ebuild based on your work. > > Changes: > * use python eclass and depend on python:2 since parts of openvswitch are > not yet compatible to python:3 > * add tcpdump as configurable runtime dependency (see README) > * add support for brcompat module (bridge compatibility layer) and related > init script > * changed socket path from /var/lib/run/openvswitch to /var/run/openvswitch > > Works fine with Xen 4.1.2 and vanilla kernel 3.2.5. > > Ebuilds for openvswitch [1] and xen-tools [2] can be found in our little > overlay. I should have filed bugs, I know... Nice work, thx. I'll try to get a complete round up including the work of Tiziano tomorrow. Afterwards I'll cleanup the bug and provide also a new live ebuild. Hope now this hits tree fast as ovs has become a vanilla feature ;)
Have had a short look at Peters xen-tools patches, really interesting, I modified existing scripts adding autodetection for ovs / brctl
I'm running OVS on a laptop providing networking to some KVM VMs. Occasionally, when the laptop is heavily loaded, networking performance will suffer excessively. I believe this is due to the ovs-vswitchd being involved in flow setup and being starved for CPU. I've been running with a tweaked version of the openvswitch-1.4.0-r2.ebuild attached here that is been revbumped to version 1.4.1 (which was released May 2nd) and which adds the following to /etc/conf.d/ovs-vswitchd.conf: # The ovs-vswitchd process is involved in new flow creation. If it # is starved by other processes then networking will suffer which may # further affect overall system performance. Running ovs-vswitchd at # a higher priority can mitigate this impact. NICE_LEVEL=-10 and the following change to start() in /etc/init.d/ovs-vswitchd.conf: start() { ebegin "Starting Open vSwitch daemon" start-stop-daemon --nice ${NICE_LEVEL} --start --quiet --exec /usr/sbin/ovs-vswitchd -- --pidfile --detach ${DB_SOCKET} eend ${?} } This setup seems to have resolved the issues I was experiencing. It would be great if these changes could be incorporated into the consolidated ebuild that is in the works.
Version 1.6.1 (for kernel 3.3+) is now in the tree. Thanks everyone.