After loads of email and IRC discussions, the Open Virtual Network (OVN) source code has been separated from the Open vSwitch (OVS) source code, and the two projects now operate independently. In this article, we'll explain the reasons for separating OVN from OVS, the technical aspects of the split, and the upcoming challenges for the OVN project.
Background
OVN was initially announced on the OVS developers mailing list in January of 2015. From the initial email announcement:
"OVN will not require a special build of OVS or OVN-specific changes to ovs-vswitchd or ovsdb-server. OVN components will be part of the Open vSwitch source and binary distributions."
The decision to include OVN in the same source distribution of OVS was done mostly out of convenience. By including it in the same source distribution, OVN could make use of bleeding-edge features of OVS without issue. OVS wouldn't need to be modified to export libraries for external programs' use. All that was needed to be done was to make an OVN subdirectory in the OVS project and put some code in there. That said, there were discussions about OVN existing in a separate repo from the beginning, and it was expected that eventually OVN would split out into its own repo. Thus, the issues became: When would it become necessary, and who would be willing to put in the work?
The present
Since the initial creation of OVN in 2015, the project has matured, and cloud management services (CMSes) have begun adopting it. At Red Hat, OpenStack and Openshift both make use of OVN for defining their virtual networks. From their point of view, they interact directly with OVN, while OVS performs more "under the hood" work. OVN is constantly getting vital new features, while OVS gets changes they don't care nearly as much about. Also, from a CMS point of view, OVS is seen as "stable." There's not as much incentive to want to upgrade the version of OVS they run on. OVS operates on a six-month release cycle, but CMSes are interested in getting the new OVN features more quickly. CMSes are satisfied with the current feature set of OVS and would prefer not to have to update OVS if they do not have to. Instead, they have to wait six months for the OVN features to be available, and then they're forced to update OVS beyond what they want to be using.
Three stages of separation
Based on this situation, discussion about separating OVN from OVS has been going on for a long time. Earlier in 2019, Red Hat made the resolution to put in the legwork to get OVN separated from OVS. The first step was to work through the technical aspects of the split. Here is a mailing list post I created outlining potential strategies for performing the separation. In the end, we came up with a three-stage plan for separating OVN from OVS.
- Stage 1: Separate the packaging of OVN from OVS.
- Stage 2: Create a separate OVN source repo, including OVS as a Git subtree.
- Stage 3: Eliminate the OVS subtree, allowing compilation of OVN using a remote installation of OVS.
We completed Stage 1 in January. A new spec file was added to the OVS distribution, and OVN's RPMs were moved to this spec file. The package names also changed at this point. When OVS 2.11 released, rather than having openvswitch-ovn-central and openvswitch-ovn-host packages, we now created ovn-central and ovn-host packages. Aside from the change in the package name, this step likely was not noticeable to users. The new package was designed so that an upgrade would transparently install the new packages.
For Stage 2, we performed a couple of trial runs separating OVN from OVS earlier this year. However, we chose not to go live with this change until after the OVS 2.12 branch was created. This way, we had a clear separation point for OVN development to happen in its own repo. The OVS 2.12 branch was created on July 22, and we performed the split the following week. Since the split, all OVN developers have targeted their new features to the new OVN repo. When OVS 2.12.0 releases, it will be the final release of OVS that also includes a companion OVN version. With Stage 2 complete, OVN has the freedom to change its release cadence; however, it also has the responsibility to maintain compatibility with multiple versions of OVS.
Stage 3 is currently under review and likely will be merged very soon. Including OVS as a Git subtree was a good stopgap for convenience, but it makes building and testing OVN a bit odd. Specifically, keeping a Git subtree up to date is not as straightforward as just keeping a separate repo on your system up to date as necessary. When running unit tests, due to the way that GNU autotest works, those tests would be run from within the OVS subtree and from OVN's tests/ directory. This could lead to annoyances when attempting to run specific OVN tests. With OVS separated out, that is no longer an issue, and it makes for much quicker testing of OVN.
An unstated (and obvious) Stage 4 is to remove the OVN code from the OVS repo. We have a patch series on the mailing list that does this, but it is still awaiting approval.
The future
The "physical" aspect of separating OVN from OVS is complete. However, we still face many challenges going forward. The biggest problem is coming up with policies for maintaining compatibility between OVN and OVS. I have started a mailing list discussion with a document that lays out a potential solution to this.
The question of how we plan to version OVN from here on is also an issue. Given how CMSes are hoping to be able to use newer OVN features more rapidly, it may make sense to release new versions of OVN more quickly than every six months. Previously, OVN was included as part of each OVS release. So, it was required to have matching versions of OVN and OVS. However, if we are releasing OVN more frequently than OVS, the version numbers will end up skewing, potentially resulting in confusion. Thus, we may change the versioning scheme of OVN altogether. I have started a mailing list discussion with a document that proposes a shorter release cycle and a new version numbering scheme.
Many smaller cleanup tasks also need to be done. For instance, the Documentation folder still contains many references to "Open vSwitch" instead of "OVN." OVS had some supplementary material for convenience. For example, it contained files for building quick vagrant environments. OVN could benefit from similar amenities.
Other administrative tasks are being worked on. For instance, work is being done to create separate mailing lists for OVN so that the multitude of OVN discussions don't "pollute" the OVS lists. There are also efforts to create a separate ovn.org website, which is separate from the openvswitch.org website.
OVN continues to grow and be a leading solution for creating virtual networks. The separation of OVN from OVS marks a milestone nearly five years in the making. With OVN separated from OVS, this is a great jumping-off point for greater new features, and a fantastic time to join in the development of the project if you are interested.
Last updated: August 29, 2019