[ovs-dev] [RFC v2] Document process for compatibility between OVS and OVN.

Ben Pfaff blp at ovn.org
Thu Sep 12 19:25:10 UTC 2019

On Fri, Sep 06, 2019 at 05:08:17PM -0400, Mark Michelson wrote:
> +===============================
> +Keeping OVN Compatible with OVS
> +===============================
> +
> +OVN has split from OVS. Prior to this split, there was no issue with
> +compatibility. All code changes happened at the same time and in the same repo.
> +New releases contained the latest OVS and OVN changes. But now these assumptions
> +are no longer valid, and so care must be taken to maintain compatibility.

"no issue with compatibility" significantly overstates the case, since
a distributed system has to be upgraded in some order (and different
parties actually wanted different orders!).  I agree with the larger
point that the split increases the difficulty.

> +Compile-time Incompatibility
> +----------------------------
> +
> +The first way that the projects can become incompatible is if the C code for OVN
> +no longer can compile.
> +
> +The most likely case for this would be that an OVN change requires a parallel
> +change to OVS. Those keeping up to date with OVN but not OVS will find that OVN
> +will no longer compile since it refers to a nonexistent function or out of date
> +function in OVS.
> +
> +Most OVN users will consume OVN via package from their distribution of choice.
> +OVN consumes libopenvswitch statically, so even if the version of OVS installed
> +on a user's machine is incompatible at compile time, it will not matter.
> +
> +OVN developers are the only ones that would be inconvenienced by a compile-time
> +incompatibility. OVN developers will be expected to regularly update the version
> +of OVS they are using. If an OVN developer notices that OVN is not compiling,
> +then they should update their OVS code to the latest and try again.
> +
> +Developers who are making changes to both OVS and OVN at the same time *must*
> +contribute the OVS change first and ensure it is merged upstream before
> +submitting the OVN change. This way, OVN should never be in a state where it
> +will not compile.
> +
> +When compiling older releases of OVN, it should be able to compile against newer
> +versions of OVS due to API and ABI guarantees in OVS's libaries.

The above section doesn't observe the difference between minor and
major newer versions.  I believe that our current ABI/API guarantee is
for different minro versions within a major release.  It is not
necessarily the case that a newer major release has compatible ABI/API
with an older one.  (I think that we use library naming to make this

> +Runtime Incompatibility
> +-----------------------
> +
> +The next way that the projects may become incompatible is at runtime. The most
> +common way this would happen is if new OpenFlow capabilities are added to OVS as
> +part of an OVN change. In this case, if someone updates OVN but does not also
> +updage OVS, then OVN will not be able to install the OpenFlow rules it wishes
> +to.
> +
> +Unlike with compile-time incompatibilities, we can't wallpaper over the fact
> +that the OVS installation is not up to date. The best we can do is make it very
> +clear at runtime that a certain feature is not present, and if the feature is
> +desired, OVS must be upgraded.
> +
> +The following is the process that OVN developers should use when making a
> +runtime compatibility change to OVS and OVN.
> +
> +1. Submit the change to OVS first. See the change through until it is merged.
> +2. Make the necessary changes to OVN. 
> +
> +  a. At startup, probe OVS for the existence of the OpenFlow addition. If it
> +     is not present, then output an informational message that explains which
> +     OVN feature(s) cannot be used.
> +  b. If a user attempts to explicitly configure the feature that is not usable
> +     due to the incompatibility, then output a warning message.
> +  c. Ensure that the code that installs the OpenFlow will only do so if the new
> +     feature is present.

It's possible that we could introduce features for logical flows that
allow different behavior based on whether a given node supports a
particular feature.  I've thought about this in the past, but it
didn't become necessary yet.

More information about the dev mailing list