[ovs-dev] OVN/OVS Split amended proposal

[Mark Michelson]

A few weeks ago, I sent a detailed document[1] with a tasklist of what 
would need to be done to separate OVN from OVS. To summarize, the work 
was divided into four phases:

1) Physical separation.
2) Compile time compatibilty.
3) Runtime compatibility.
4) Separation of OVN and OVS packages.

Initially, the idea was to perform all four of these phases by the time 
that OVS 2.11 was released. However, there are a few problems.

In addition to this major project, there is also another major project 
involving rewrites of OVN components to use DDLog. Trying to separate 
the OVN code out could step on the toes of the efforts to convert to 
DDLog. The conversion to DDLog is going to require a lot of testing and 
verification, and the separation of the code will require even more 
testing and verification on top of it. While we like to think we'd do it 
100% correctly, there's a decent chance that we are going to introduce 
regressions.

Red Hat developers had planned to head the development effort to get the 
separation completed. Realistically, we have too many other tasks on our 
plate to guarantee the successful completion of the full separation by 
the 2.11 release.

In addition to the technical aspects of the separation, administrative 
aspects still would need to be implemented. This involves deciding the 
pace of versioning of OVN, creation of web sites and new mailing lists, 
etc. It may be possible for us to complete all this in time for the 2.11 
release, but I believe we'd feel more comfortable if we had a longer 
lead time for this.

With this in mind, we'd like to propose an amended plan.

The short version: rather than completing all four phases by the 2.11 
release, instead we will implement phases 3 and 4 for 2.11, and then 
complete phases 1 and 2 for 2.12.

What this means is that we will change the packaging so OVN is no longer 
a sub-package of OVS. Rather, OVN will be an independent package, 
allowing it to be updated without having to also update OVS.  By 
attacking the problem this way, we scratch an itch somewhat by allowing 
for projects to move forward with newer OVN builds while remaining on 
their current version of OVS. What we won't get is the ability for OVN 
to be developed and versioned at a separate pace.

In order to facilitate this, OVS will need to be outfitted with ways for 
OVN to probe for the existence of features at runtime. The most obvious 
use of this would be ovn-controller querying ovs-vswitchd about the 
existence of certain OpenFlow match fields and actions.

We believe this is a more realistically achievable goal, is less likely 
to conflict with other development projects, and is less likely to 
result in bugs being introduced. Since this plan directly implements 
phases that are necessary for the full separation, it acts as a stepping 
stone rather than a band-aid or stop-gap.

What are your thoughts on this?

Mark Michelson

[1] 
https://mail.openvswitch.org/pipermail/ovs-dev/2018-September/352414.html