[ovs-dev] Open vSwitch Debian package maintainership

Ben Pfaff blp at ovn.org
Tue Jun 19 16:44:20 UTC 2018

On Mon, Jun 18, 2018 at 11:31:03PM +0200, Thomas Goirand wrote:
> On 06/18/2018 09:56 PM, Ben Pfaff wrote:
> > Hi Thomas.  Thanks for the latest upload of the Open vSwitch packages to
> > Debian.
> > 
> > I'm no longer interested in being a maintainer for the downstream Debian
> > packages of Open vSwitch.  I just don't have sufficient time to do it
> > properly (and honestly have not had that time for at least a few years).
> > The next time you make an upload, would you mind removing me from the
> > Maintainers field?
> > 
> > Thanks,
> > 
> > Ben.
> Ben,
> Reading the above is very frustrating. Yes, I know how to do packages,
> but I really need help from upstream. In many ways, I do need help from
> upstream, and especially from someone knowing packaging. I very much
> would prefer if you could reconsider your above decision. Even if you
> don't do the bulk of the work, I will need help when there's FTBFS and such.
> For example, currently, OpenVSwitch can build because I have patched the
> unit test suite to remove lots of tests. I would very much prefer if I
> had real fixes, rather than disabling them.
> There's also areas that I don't really understand (yet?). For example, I
> have yet understood what DPDK is, and how I should package it. The only
> way I could do it would be cheating by reading what has been done in
> Ubuntu. That's not the way I want to continue doing the work. I don't
> really get what is the difference between OVS and OVN as well.
> So, definitively, please continue to help!

I didn't intend to increase your frustration, only to acknowledge that I
haven't been helping in the primary way that a Debian developer should
for packages that he/she/they maintains (by updating packaging and
building and uploading it) and that this probably won't change.

Everything you mention is the sort of thing that I (and others on the
ovs-dev mailing list) can actually help with, though.  Maybe you have
brought up some of these before, although I don't recall it.  Sometimes
the list is busy, or the people who read the list are busy, and
questions don't get answered, and in that case it's best to ask again a
while later.

I can help to address some of these issues now.

Debian-wise, the unit tests are a bit of an exercise in frustration
themselves.  Some of the OVS unit tests are timing sensitive.  We have
spent quite a bit of work on that, but it's difficult to be perfect (and
we have a lot of tests!)  There are two things that distinguish the
tests running on Debian buildds.  First, Debian has far more
architectures than any other distro, which means that really odd
failures show up.  This is usually an advantage because we find a wider
range of bugs, but occasionally something comes up that is very
difficult to debug.  Second, the buildds really seem to bring out the
worst in the tests somehow.  I've sometimes tried to reproduce the
timing-related failures anywhere else (on my own machine, on Debian
machines, ...) and they just won't.  That makes it really hard to deal
with them.

About DPDK, well, DPDK is a library for userspace networking.  It takes
control of network interfaces away from the kernel, using its own
network drivers, and processes packets in userspace.  It's generally
much faster than kernel networking because it's more specialized (less
general-purpose) and because of a number of clever tricks it does.  OVS
can take advantage of DPDK if it is configured to do so.  In my opinion,
the ideal way to add DPDK support to OVS would be to just link it into
the main binary, since OVS is designed to use it if it is configured to
do so or not use it otherwise and therefore OVS with DPDK is strictly
more useful than OVS without it.  However, last I checked the DPDK
library itself has some nastiness like doing CPU checks at startup time
and aborting if the CPU isn't suitable in some way (it's pickier than
Debian is about CPU features), so I guess that having it in a separate
package is probably the realistic approach.  (The separate package
wouldn't need to be anything other than an alternate ovs-vswitchd
binary, perhaps substituted for the non-DPDK version using dpkg-divert

OVS versus OVN: Probably you know what OVS is already.  Where OVS is a
programmable switch, OVN is an application that runs on top of it.  OVN
is an OpenFlow controller plus a centralized database that allows a
cloud management system like OpenStack or Kubernetes (with appropriate
plugins) to control the networking in a collection of hypervisors.
We're talking about breaking OVN apart from OVS as a separate project;
OVS has been a great place to incubate the OVN project, but the two are
logically distinct.

More information about the dev mailing list