[ovs-dev] OVN/OVS Split amended proposal

[Flavio Leitner]

Hi,

On Fri, Nov 02, 2018 at 03:13:35PM -0400, Mark Michelson wrote:
[...]
> 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?

It sounds good.  Today in the spec file we don't require any specific
version of OVS in the OVN sub-packages, so we might want to consider
things like requiring the same major version or the initial version
like 2.11 or newer, at least.  My concern is that there are 2.6 out
there which might not be interesting for OVN of today to support.

Another thing is that from a distribution point of view, there is only
one main package with optionally many sub-packages. So, you have two
possibilities here:

1) Remain as a RPM sub-package. You build everything and use only the
OVN packages you want. This would be an exception from the distributions
perspective since it is not usual to ship only sub-packages.

2) Split OVN and OVN into two independent packages. This would be the
ideal for the future when the projects split finally happens, but
requires distributions to add the new package. The inclusion in fedora
and RHEL are not trivial, so I'd say to start as soon as possible if
you want to be live with 2.11.  You will need a maintainer and most
probably a co-maintainer. I don't know the specifics for Debian or
Ubuntu.

Another thing is how to track the sources. Today you would have two
copies of the openvswitch tarball for both packages, which is not
ideal but ok. However, currently it is not very clear which patch goes
to each project. That means duplication of work backporting/applying
patches to two projects or that there is risk of missing patches in
one or another.  For instance, a bug fix in a lib. Does that apply
only to OVN or only to OVS or both?  Upstream would be fine since it
is still one thing, but not sure how to keep both packages okay.

When you build the OVN packages, should it use the OVS sources in the
tarball or use the headers and libs from the installed OVS package?

fbl