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 clear.) > +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. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
