A few weeks ago, I sent a detailed document[1] with a tasklist of what
would need to be done to separate OVN from OVS. To summarize, the work
was divided into four phases:
1) Physical separation.
2) Compile time compatibilty.
3) Runtime compatibility.
4) Separation of OVN and OVS packages.
Initially, the idea was to perform all four of these phases by the time
that OVS 2.11 was released. However, there are a few problems.
In addition to this major project, there is also another major project
involving rewrites of OVN components to use DDLog. Trying to separate
the OVN code out could step on the toes of the efforts to convert to
DDLog. The conversion to DDLog is going to require a lot of testing and
verification, and the separation of the code will require even more
testing and verification on top of it. While we like to think we'd do it
100% correctly, there's a decent chance that we are going to introduce
regressions.
Red Hat developers had planned to head the development effort to get the
separation completed. Realistically, we have too many other tasks on our
plate to guarantee the successful completion of the full separation by
the 2.11 release.
In addition to the technical aspects of the separation, administrative
aspects still would need to be implemented. This involves deciding the
pace of versioning of OVN, creation of web sites and new mailing lists,
etc. It may be possible for us to complete all this in time for the 2.11
release, but I believe we'd feel more comfortable if we had a longer
lead time for this.
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?
Mark Michelson
[1]
https://mail.openvswitch.org/pipermail/ovs-dev/2018-September/352414.html
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
