> On Thu, Mar 11, 2021 at 6:11 PM Ben Pfaff <mailto:b...@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). > > 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)
Semantic versioning of OVSDB API would surely enable better compatibility between the projects. As of right now, static linking in OVN RPM packages for instance can be easily disabled. My tests showing that it can be beneficial in environments where we can have controlled upgrades. But without versioned OVSDB API it is just too dangerous to have that as a default. As I also expressed in ovsorbit podcast, separation of OVSDB from OVS could potentially help us expand user base beyond just OVS use cases. I've built OVSDB-KV prototype in Go and did some comparison to ETCD (see slides that Ben listed in podcast reference #e72) and found quite significant performance gains, granted after few changes to OVSDB that I proposed. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
