Hello, Mark, On Mon, Jul 11, 2022 at 8:23 PM Mark Michelson <mmich...@redhat.com> wrote: > Last Thursday, during the OVN IRC meeting, you brought up the topic of > how to better handle the OVS submodule within OVN. As I recall, the > issue was that in Ubuntu, you can't download an arbitrary commit of OVS > strictly for compiling against OVN. You instead need to use the > installed OVS package on the system. In the meeting we focused on trying > to come up with policies to ensure that the submodule points to a > release branch of OVS.
Yes, I believe the main concern for us is that we want to make sure we build, package and distribute binaries based on actually upstream released artifacts. The secondary concern would be availability of the OVN build time dependencies within the distribution where we want to build it. To mention a concrete example: OVN 22.03.1 currently has a build time dependency on [0] which at the time of this writing is not a part of any OVS release. After the discussion it became apparent that it most likely will become available with the release of OVS 2.18, however OVS 2.18 will not be a part of the distribution we currently ship OVN 22.03.x in, herein lies the difficulty. > However, Ilya brought up an alternate idea today. Currently, the release > tarball of OVN in github is strictly the OVN code with no submodule. If > there were a way to make the source tarball also include the OVS > submodule, then it should be enough to get the OVN source tarball and > compile it on its own. There would be no need to care about the version > of OVS installed on the system. > > Would this solve the issue you are facing? If so, then we can focus on > coming up with an alternate method of creating source tarballs instead > of using the tag in github directly. This is a great offer, and it would indeed solve the build time issues for us. There are some standing guidelines that may conflict with this type of bundling [1], but in this case I would argue that if we compare the sum of the equation of building OVN with its bundled OVS dependency from a upstream tarball vs. having to maintain multiple versions of OVS within the same archive, the bundled upstream tarball would come out with a lower cost. The only concern I would like to address is some sort of formal agreement about runtime compatibility between the current OVN LTS release (22.03.x) and OVS LTS release (2.17.x). Would you accept proposals in that direction to the OVN release documentation? 0: https://github.com/openvswitch/ovs/commit/d94cd0d3eec33e4290d7ca81918f5ac61444886e 1: https://wiki.debian.org/UpstreamGuide#No_inclusion_of_third_party_code -- Frode Nordahl > > Thanks, > Mark Michelson > _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
