[ovs-dev] [PATCH ovn] ovs: Bump submodule version to latest ovsdb-cs changes.

Ilya Maximets i.maximets at ovn.org
Fri Mar 12 10:53:22 UTC 2021

On 3/12/21 7:42 AM, Han Zhou wrote:
> On Thu, Mar 11, 2021 at 6:11 PM Ben Pfaff <blp at ovn.org <mailto:blp at ovn.org>> wrote:
>> On Thu, Mar 11, 2021 at 08:07:58PM -0500, Mark Michelson wrote:
>> > On 3/11/21 5:58 PM, Ilya Maximets wrote:
>> > > I'd say that eventually OVN should become less feature hungry
>> > > or less dependent from OVS changes.  Then we should consider
>> > > to use only stable released OVS as a build dependency and
>> > > actually wait for the next major OVS release if some new features
>> > > required from it.  But right now we can't afford that.
>> >
>> > I'd say the vast majority of the time these days, the OVS changes OVN
>> > depends on are specifically OVSDB changes. One possible idea is to separate
>> > OVSDB from OVS and semantically version the OVSDB API. Then OVS and OVN
>> > would be consumers of the same common project.
>> >
>> > You'd still have the potential for needing to update the OVS submodule to
>> > some non-released version. But hopefully the frequency of such updates would
>> > be reduced. And if the frequency is reduced enough, it probably wouldn't be
>> > outside the realm of reason to request backports of bug fixes and
>> > point-releases of OVS whenever OVN requires a submodule update.
>> I'm adding Dmitry Yusupov to this thread because he expressed some
>> interest in separating OVSDB from OVS in the latest OVS Orbit episode
>> (https://ovsorbit.org/#e72 <https://ovsorbit.org/#e72>).
> I think this is not only a dependency problem of compiling, but also of runtime, if we want to continue supporting debian, because in debian packages dynamic linked library is used instead of statically linked. If I understand correctly, the submodule approach solves the compile time dependency but not runtime, for debian. So the only way out eventually might be separating OVSDB from OVS. (Please correct me if I am wrong)

OVS doesn't export too much in public libraries.  However, splitting
out OVSDB is not just splitting OVSDB itself.  It's he same as  splitting
OVN.  OVSDB parts just like OVN depends on all the internal non-exported
data structures and utility functions. So, there are several ways to
handle that:

a. OVN way: Keep data structures and stuff inside OVS sources and have
   OVS as a build dependency for both OVN and OVSDB.
   This way we'll have all the same issues with OVSDB as we have with
   OVN.  We'll end up creating an OVS submodule for OVSDB or something
   similar.  Will have to synchronize releases of 3 separate projects
   at the same time.

b. Split out all libraries to a 4th project and maintain it separately.
   In this case we will have to maintain public API/ABI compatibility
   for libraries, version all the APIs and waste lots of time maintaining
   while loosing a flexibility and speed of modification or addition of
   new functions or libraries.

c. Copy out all the libraries to all dependent projects.
   This will bring lots of code duplication across 3 different projects
   and consequent requirement to track all changes/fixes and port to other

All 3 options above looks to me more like a maintainers' hell.

Best regards, Ilya Maximets.

More information about the dev mailing list