Hi, On Fri, Nov 02, 2018 at 03:13:35PM -0400, Mark Michelson wrote: [...] > 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?
It sounds good. Today in the spec file we don't require any specific version of OVS in the OVN sub-packages, so we might want to consider things like requiring the same major version or the initial version like 2.11 or newer, at least. My concern is that there are 2.6 out there which might not be interesting for OVN of today to support. Another thing is that from a distribution point of view, there is only one main package with optionally many sub-packages. So, you have two possibilities here: 1) Remain as a RPM sub-package. You build everything and use only the OVN packages you want. This would be an exception from the distributions perspective since it is not usual to ship only sub-packages. 2) Split OVN and OVN into two independent packages. This would be the ideal for the future when the projects split finally happens, but requires distributions to add the new package. The inclusion in fedora and RHEL are not trivial, so I'd say to start as soon as possible if you want to be live with 2.11. You will need a maintainer and most probably a co-maintainer. I don't know the specifics for Debian or Ubuntu. Another thing is how to track the sources. Today you would have two copies of the openvswitch tarball for both packages, which is not ideal but ok. However, currently it is not very clear which patch goes to each project. That means duplication of work backporting/applying patches to two projects or that there is risk of missing patches in one or another. For instance, a bug fix in a lib. Does that apply only to OVN or only to OVS or both? Upstream would be fine since it is still one thing, but not sure how to keep both packages okay. When you build the OVN packages, should it use the OVS sources in the tarball or use the headers and libs from the installed OVS package? fbl _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev