[ovs-dev] [RFC v2] Document process for compatibility between OVS and OVN.
mmichels at redhat.com
Thu Sep 12 20:06:14 UTC 2019
On 9/12/19 3:25 PM, Ben Pfaff wrote:
> 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
>> +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.
I'm curious how this would operate. I tend to think of logical flows as
describing a feature at a high level. It's then up to ovn-controller to
translate this as appropriate. So I would think the logical flow would
not be interested in what the node's datapath supports, since the node
is free to translate the logical flow as it sees fit.
I guess this would be useful if the presence of a feature on a node
might affect subsequent logical flows beyond the current one being
More information about the dev