Thinking Out Loud: OVS and the Enterprise

Over the last few days, I’ve been unsuccessfully trying to get Open vSwitch (OVS) running on Red Hat Enterprise Linux (RHEL) 6.3 (as well as CentOS 6.3). The rationale behind this is that RHEL/CentOS are the sort of battle-tested, well-supported Linux distributions that enterprises will (and do) deploy in their data centers. OVS, of course, is central to the strategy and functionality of several network virtualization players and projects:

  • Nicira
  • Midokura (more information here)
  • OpenStack Quantum

If you follow me on Twitter, you’ve probably noticed me talking about trying to rebuild source RPMs, running into all sorts of dependency issues, encountering errors when compiling, patching files, etc. I still haven’t achieved success (yet), but I’m going to keep trying—for a little while longer, at least.

And this is what brings me to the central thought in this Thinking Out Loud post. I’m no expert—especially in this area, where I’m still learning more and more every day—but shouldn’t projects like OVS just work with enterprise-class Linux distributions? I mean, if you’re going to build network virtualization products that attempt to bring cloud computing-style functionality to enterprise networks, don’t you kind of need a core part of your solution to work on the Linux distributions that enterprises will actually deploy? Yes, it’s great that OVS ships with Fedora 17, and that it works (so I’ve been told, I haven’t actually tried it personally). But what organization is going to deploy Fedora 17 to help support an important function like network virtualization? They won’t. Doesn’t it make sense for the developers behind projects like OVS to really pay attention to the distributions that are most likely to be used by their current (and potential) customers?

It really boils down to this: if OVS is going to see adoption in the enterprise, wouldn’t it make sense to improve its support on enterprise-focused Linux distributions?

I’m new to a lot of this stuff, so I freely admit I that I could be just missing some key piece of information here. So help me out—what I am missing? What am I overlooking? Speak up below—all courteous comments are welcome.

Tags: , , , ,

  1. Timothy Patterson’s avatar

    You could always go with SLES 11 or openSUSE 12.2. There are packages ready to go on the build service site: http://software.opensuse.org/package/openvswitch

    As far as building SRPMS from Fedora on CentOS, it is usually a shot in the dark due to the drastic differences in the systems. Even though they are both based on RedHat, Fedora is vastly newer than CentOS/RHEL. RedHat is notorious for patching existing versions of their packages instead of going with newer software.

    Try following these steps for CentOS 6.3: http://n40lab.wordpress.com/2012/09/19/installing-openvswitch-in-centos-6-3/

    If you run into issues there, let me know what errors you are getting and I will help you out. :-)

  2. Ken.C’s avatar

    It’s a similar problem with the OpenStack components (or at least it was when we tried it earlier this year). I think the issue is that Ubuntu is the new hotness with all the new libraries, etc., so that’s where all the developers want to go. Meanwhile, those of us on the datacenter side of things aren’t so comfortable with all that might-as-well-be-beta stuff.

  3. Sergei Hanus’s avatar

    It looks like Redhat plans to implement OVS in their next major release – RHEL 7. I didn’t see it in roadmaps, but here – http://www.youtube.com/watch?feature=player_embedded&v=44ZMo84mQ5g – at the end of presentation (appr., 59:14) there’s a slide which says that there are such plans. But, it’s still H2 2013 :)

  4. Jonathan Barber’s avatar

    But most Enterprises won’t deploy Fedora 17 to run OVS, instead they will buy the RedHat Enterprise Virtualization / Oracle Enterprise Virtualization / Xen / whatever product which includes OVS in the installation. OVS becomes a part of the packaged product in the same way that VMware’s vSwitch or VDS is part of the ESX product.

    By the way, I use mainly RHEL based products (i.e. RHEL/Centos/Fedora) for my production workloads. But when I started looking at OVS I decided that I wasn’t interested in spending the time to get it to work under RHEL – so I switched to using Debian for the hypervisor to make it simple to get it running.

  5. slowe’s avatar

    Timothy, thanks for your comment. I wanted to focus on RHEL/CentOS since those are the distributions that tend to be most common in enterprise environments. Your article looks quite helpful. I gave it a quick run-through but encountered some errors with boot.sh; it reported unable to exec aclocal. I may try again later—we’ll see.

    Ken C, I agree, and this is something that really needs to be resolved. I’m not sure if more commercial distributions of OpenStack will help with the apparent disconnect; time will tell.

    Sergei, and when RHEL 7 does ship with OVS, will it be a recent enough version to support the features that enterprises need? If it isn’t, will newer versions compile correctly? That’s kind of the point here.

    Jonathan, you hit the nail on the head! Enterprises aren’t going to deploy Fedora, or even a non-LTS version of Ubuntu. Yet, those are the places that most need these packages made available. I spoke with the Red Hat folks last week at VMworld in Barcelona—the current version of RHEV (3.0) doesn’t have OVS, and the next version of RHEV (3.1, now available in oVirt) doesn’t have OVS either. As for RHEL vs. Debian: let’s just say I’m about to install Ubuntu again (12.10 this time) so that I can actually make some progress.

  6. Florian’s avatar

    Hi Scott,

    Well, I understand your problems, but I have a slightly different take on things.

    You either go bleeding edge and are content with compiling stuff like e.g. OVS from source code (and no, source RPMs do _not_ qualify) or wait until a vendor packages that for you in an “Enterprise grade” offering. Mixing the two just doesn’t work in my experience.

    The harsh reality is that OVS and SDN solutions like the ones you list in the article are not (at least AFAIK) avail in packages for the general audience, much less the fabled “enterprise”. I hear your point about “OVS adoption in the enterprise” but bashing Linux distros for not including that is just the wrong take at it IMO.

    If you want any of the solutions like the ones you list to “make it in the enterprise” I’m sure the vendors behind them are more than ready to help and make the whole thing work for you. Just picking OVS out of the whole mix and asking the Linux distros to do that is not going to happen, at least not any time soon.

    My $0.02

    Cheers,

    Florian

  7. Timothy Patterson’s avatar

    Scott, did you enable the EPEL repo? The aclocal version is newer there I believe…

  8. slowe’s avatar

    Florian, thanks for your comment. The one thing that I didn’t mention in my article is exactly what you’ve picked up on it seems–that there are plenty of commercial vendors willing to “hide the open source complexities,” as it were, inside their own commercial distributions. Certainly that is a path that we have seen and will continue to see taken as projects like OVS move forward. And while my post was focused on OVS, the same could be said for a number of open source projects.

    However, wouldn’t it make as much sense for the developers to be aware of the target consumers of their code, and develop accordingly? Perhaps that is the root of my problem—perhaps that is exactly what they are doing right now, and I just haven’t recognized that the enterprise isn’t their target consumer. Thoughts?

  9. slowe’s avatar

    Timothy, I’m pretty sure that the EPEL repository was enabled. I’ll double-check next time I get a whim to work with RHEL/CentOS again.

  10. Paul’s avatar

    We’ve moving away from RHEL to Ubuntu LTS releases @ $dayjob. Stability is good, but being ancient also has its downsides. In place OS upgrades fully supported via apt are going to make my team’s job easier.

    Anything related to “the cloud” moves at such a pace that getting it all running on a RHEL clone is journey full rpmbuild and spec file fun.

    Since most of our stack is on Java (which we don’t use the RHEL openjdk packages for anyway) staying on RHEL doesn’t really benefit us much vs what Ubuntu LTS can deliver. The supported period is long enough on LTS. Also considering tools like puppet & chef mean that rebuilding your systems isn’t that much of a pain.

    Factor in the increasingly poor support from Red Hat (haven’t had a really good outcome in the last 3 years) we are now jumping ship.

    The added benefit of this is our production environment is much closer to what the developers develop on. Resulting in less time spent back porting libraries for releases into production infrastructure.

  11. Dmitri Kalintsev’s avatar

    Is it possible that the developers, being part of commercial organisations offering integrated solutions, are naturally inclined to pay more attention to getting things work within the confines of the said integrated solutions?

    I may be miles off the base here, but just a thought… And yes, for those trying to assemble things ourselves, things do vaguely resemble “good old” days of “less README; less INSTALL; ./configure –whatever ; make; make install” with a lot of wget’ing, tar xvzf’ing, rinsing and repeating in between, sprinkled with occasional kernel rebuilds…

  12. Ken.C’s avatar

    I suppose we should look at it like this: the devels are skating where the puck will be by the time it gets out to the enterprise. By the time anyone enterprise will actually consider OVS, perhaps it’ll be available on the common yum repos for RHEL 8 or something.

    Or Ubuntu will have taken over the world and I’ll have finally gotten used to its crazy way of doing things.

  13. Chris Cowley’s avatar

    I hear your pain Scott, but there is no point in the OVS developers targeting the current RHEL when they start writing. By the time they are stable that release will have been and gone (even though it is still supported). They will constantly have to be re-basing on a very different target.

    Instead they work on the regular, but small changes involved in basing on Fedora. Hopefully they will find that they are stable at just the right time for Red Hat to put it in the hands of enterprises and everyone is happy.

    Also, if Red Hat feel that it is stable enough, there is a reasonable change they will backport it to RHEL6 – just as they did with KVM

  14. Chris Cowley’s avatar

    @Timothy Patterson aclocal is not in EPEL. Also it never would be as that goes contrary to the stated aims of EPEL. It is EXTRA packages, not UPDATED packages. They will only have a package that upgrades an existing RHEL package as a last resort.

    There are plenty of repos that upgrade existing packages, but EPEL is not one of them.