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 
+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 
+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 
+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 
+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 
+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 evaluated, though.
dev mailing list

Reply via email to