On 7/5/22 20:28, Gregory Rose wrote: > > > On 6/29/2022 3:42 PM, Ilya Maximets wrote: >> On 6/10/22 02:31, Frode Nordahl wrote: >>> On Fri, Jun 3, 2022 at 4:16 PM Frode Nordahl >>> <frode.nord...@canonical.com> wrote: >>>> >>>> On Thu, Jun 2, 2022 at 6:58 PM Ilya Maximets <i.maxim...@ovn.org> wrote: >>>>> >>>>> On 6/1/22 22:53, Gregory Rose wrote: >>>>>> >>>>>> >>>>>> On 5/31/2022 12:22 PM, Frode Nordahl wrote: >>>>>>> On Tue, May 31, 2022 at 7:05 PM Ilya Maximets <i.maxim...@ovn.org> >>>>>>> wrote: >>>>>>>> >>>>>>>> On 5/31/22 17:36, Gregory Rose wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 5/25/2022 6:47 AM, Flavio Leitner wrote: >>>>>>>>>> >>>>>>>>>> Hi Greg, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, May 23, 2022 at 09:10:36PM +0200, Ilya Maximets wrote: >>>>>>>>>>> On 5/19/22 20:04, Gregory Rose wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 4/15/2022 2:42 PM, Greg Rose wrote: >>>>>>>>>>>>> It is time to remove support for the OVS kernel driver and push >>>>>>>>>>>>> towards use of the upstream Linux openvswitch kernel driver >>>>>>>>>>>>> in it's place [1]. >>>>>>>>>>>>> >>>>>>>>>>>>> This patch series represents a first attempt but there are a few >>>>>>>>>>>>> primary remaining issues that I have yet to address. >>>>>>>>>>>>> >>>>>>>>>>>>> A) Removal of debian packing support for the dkms kernel driver >>>>>>>>>>>>> module. The debian/rules are not well known to me - I've >>>>>>>>>>>>> never >>>>>>>>>>>>> actually made any changes in that area and do not have a >>>>>>>>>>>>> well formed understanding of how debian packaging works. >>>>>>>>>>>>> I wil >>>>>>>>>>>>> attempt to fix that up in upcoming patch series. >>>>>>>>>>>>> B) Figuring out how the github workflow - I removed the tests I >>>>>>>>>>>>> could find that depend on the Linux kernel (i.e. they use >>>>>>>>>>>>> install_kernel() function. Several other tests are >>>>>>>>>>>>> failing >>>>>>>>>>>>> that would not seem to depend on the Linux kernel. I need >>>>>>>>>>>>> to >>>>>>>>>>>>> read and understand that code better. >>>>>>>>>>>>> C) There are many Linux specific source modules in the datapath >>>>>>>>>>>>> that >>>>>>>>>>>>> will need eventual removal but some headers are still >>>>>>>>>>>>> required for >>>>>>>>>>>>> the userspace code (which seems counterintuitive but...) >>>>>>>>>>>>> >>>>>>>>>>>>> Reviews, suggestions, etc. are appreciated! >>>>>>>>>>>>> >>>>>>>>>>>>> 1. >>>>>>>>>>>>> https://mail.openvswitch.org/pipermail/ovs-dev/2022-April/393292.html >>>>>>>>>>>> >>>>>>>>>>>> I would like to suggest at this time that rather than removing the >>>>>>>>>>>> OVS >>>>>>>>>>>> Linux kernel path that we "freeze" it at Linux 5.8. This will make >>>>>>>>>>>> it >>>>>>>>>>>> easier for some consumers of OVS that are continuing to support the >>>>>>>>>>>> Linux kernel datapath in old distributions. >>>>>>>>>>>> >>>>>>>>>>>> The ultimate goal of shifting toward DPDK and AFXDP datapaths is >>>>>>>>>>>> still >>>>>>>>>>>> preserved but we are placing less burden on some consumers of OVS >>>>>>>>>>>> for >>>>>>>>>>>> older Linux distributions. >>>>>>>>>>>> >>>>>>>>>>>> Perhaps in suggesting removal of the kernel datapath I was being a >>>>>>>>>>>> bit >>>>>>>>>>>> overly aggressive. >>>>>>>>>>>> >>>>>>>>>>>> Thoughts? Concerns? Other suggestions? >>>>>>>>>>> >>>>>>>>>>> Hi. I think we discussed that before. Removal from the master >>>>>>>>>>> branch >>>>>>>>>>> doesn't mean that we will stop supporting the kernel module >>>>>>>>>>> immediately. >>>>>>>>>>> It will remain in branch 2.17 which will become our new LTS series >>>>>>>>>>> soon. >>>>>>>>>>> This branch will be supported until 2025. And we also talked about >>>>>>>>>>> possibility of extending the support just for a kernel module on >>>>>>>>>>> that >>>>>>>>>>> branch, if required. It's not necassary to use the kernel module >>>>>>>>>>> and >>>>>>>>>>> OVS form the same branch, obviously. >>>>>>>>>>> >>>>>>>>>>> Removal from the master branch will just make it possible to remove >>>>>>>>>>> the maintenance burden eventually, not right away. >>>>>>>>>>> >>>>>>>>>>> And FWIW, the goal is not to force everyone to use userspace >>>>>>>>>>> datapath, >>>>>>>>>>> but remove a maintenance burden and push users to use a better >>>>>>>>>>> supported >>>>>>>>>>> version of a code. Frankly, we're not doing a great job supporting >>>>>>>>>>> the >>>>>>>>>>> out-of-tree module these days. It's getting hard to backport bug >>>>>>>>>>> fixes. >>>>>>>>>>> And will be even harder over time since the code drifts away from >>>>>>>>>>> the >>>>>>>>>>> version in the upstream kernel. Mainly because we're not >>>>>>>>>>> backporting >>>>>>>>>>> new features for a few years already. >>>>>>>>>>> >>>>>>>>>>> Does that make sense? >>>>>>>>>> >>>>>>>>>> Any thoughts on this? The freeze time is approaching, so it would >>>>>>>>>> be great to know your plans for this patch set. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> fbl >>>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Flavio and Ilya, >>>>>>>>> >>>>>>>>> I'll go ahead with the plans as per previous agreements - having >>>>>>>>> issues >>>>>>>>> with removing the debian kernel module support since I have never >>>>>>>>> worked on debian rules type make environments. I seem to break >>>>>>>>> something with every attempt but I will keep at it. >>>>>>>>> >>>>>>>>> What's my time frame before the freeze? >>>>>>>> >>>>>>>> The "soft-freeze" supposed to be on July 1st. The branch creation >>>>>>>> for a new release - mid July. It would be great if we can get this >>>>>>>> in before the soft freeze, but branching point is also fine. >>>>>>>> So, we have about 6 weeks. >>>>>>>> >>>>>>>> If you can think of any part of the work that can be done separately >>>>>>>> by someone else, we could try and find someone to help you out. I'm >>>>>>>> not sure if we have experts on debian packaging though. Maybe we >>>>>>>> can ask some folks from Canonical. They do their own packaging, but >>>>>>>> should know a thing or two about packaging in general. >>>>>>> >>>>>>> We'd be happy to help out with the packaging bits. >>>>>>> >>>>>>> Both Debian and Ubuntu have drifted away from what is currently in the >>>>>>> debian/ folder in the OVS and OVN repositories. This state is >>>>>>> problematic because from time to time someone tries to build packages >>>>>>> from the OVS/OVN debian package source and then expect that package to >>>>>>> work with up-/down-grades from-/to/ distro versions. >>>>>>> >>>>>>> So we would prefer to either remove what's there and replace it with a >>>>>>> README pointing to Debian and Ubuntu package sources, or update what's >>>>>>> there to match packaging state du jour. >>>>>>> >>>>>> >>>>>> I'm fine with either solution but someone else would have to update the >>>>>> debian packaging. If just removing then I could do that and then update >>>>>> the documentation. >>>>>> >>>>>> I'll wait to see what the consensus is. >>>>> >>>>> I think, you may go ahead and work on/submit the rest of the changes >>>>> without debian packaging. And we'll figure this part out separately, >>>>> either by fixing up our packaging in a separate patch or by replacing >>>>> it altogether with a version close to the current state in distros. >>>>> What do you think? >>>>> >>>>> >>>>> Frode, thanks for looking at this problem! I think that having a way >>>>> to build packages right from the sources is beneficial for some users, >>>>> e.g. to quickly try new features/releases. Re-building of the >>>>> packages from the distribution is not a very straightforward process. >>>> >>>> Thank you for weighing in with your opinion on this. We'll work in >>>> this direction then. >>>> >>>>> But, yes, there are several issues with the current debian packaging >>>>> in OVS repo. e.g. our python packaging is mostly broken and some >>>>> other things are not in a very good shape. >>>>> >>>>> I think that updating the packaging code to match what is currently >>>>> in Ubuntu/Debian should be a good move, as long as it is not tied >>>>> to one particular distribution. Patches are very welcome! >>>> >>>> That sounds feasible to me. We have a tradition for upstreaming >>>> package sources to Debian so that the diff in Ubuntu is as small as >>>> possible. So upstreaming it all the way to the origin project would >>>> not be at odds with that. I'll work on a proposal and seek agreement >>>> with the Debian maintainers and see where we get with that. >>>> >>>>> Do you know what are the main differences between current OVS upstream >>>>> version and Ubuntu/Debian packaging code? AFAIU, you're not building >>>>> the dkms module already? >>>> >>>> The dkms package was removed from Ubuntu in 2014, Debian did the same [0]. >>>> >>>> The main differences from upstream OVS would be: >>>> - Debian/Ubuntu provide a openvswitch-switch-dpdk package that >>>> integrates with a dpdk package in the distributions so that end users >>>> can opt into a DPDK-enabled Open vSwitch binary >>>> - Debian/Ubuntu use systemd and the package provides systemd service files >>>> - Debian/Ubuntu provide openvswitch-source package for use when doing >>>> integrated build of OVN >>>> - None of them provide the libopenvswitch and libopenvswitch-dev packages >>>> >>>> The main difference between Debian and Ubuntu would be: >>>> - Ubuntu builds OVS statically while Debian use `--enable-shared` >>>> - Ubuntu provides systemd services to delay recording of hostname >>>> until network is up ref [1] >>>> >>>> 0: >>>> https://salsa.debian.org/openstack-team/third-party/openvswitch/-/blob/c4c329b15cafee9ccc7ce724c0fc8aa5b7d33881/debian/changelog#L922-L937 >>>> 1: >>>> https://github.com/openvswitch/ovs/commit/2ad201659cedbb1134a9d27af132e491173c7e40 >>> >>> An update on this: We're currently in conversations with Debian >>> maintainers of OVS and OVN to more closely coordinate the packaging >>> between the Debian and Ubuntu projects. I however do not know if those >>> conversations will conclude before the OVS 2.18 freeze. >>> >>> To support the proposed removal of the out of tree build of dkms >>> packages and unblock this thread of work I would propose to push the >>> current state of OVS packaging from Ubuntu to the upstream repository. >>> I would be ready to work on this in the week of June 27th through July >>> 1st. Both projects currently override the upstream debian/ folder with >>> their own sauce so we would not be breaking Debian nor Ubuntu with >>> such a change, and we would at the same time support you moving >>> forward with this work. >>> >>> What do you think? >>> >> >> Thanks, Frode! I see you submitted patches, I'll take a look at >> them somewhere soon. >> >> @Greg, are there any news on the main kernel module removal work? >> We're getting close to branching for the next release in ~2 weeks, >> it would be great to have this work finalized before that. >> If you don't have enough time, we could also find someone to take >> this task over. Just let us know. >> >> Best regards, Ilya Maximets. > > Hi, > > I'll repost my patches that remove the kernel module this afternoon > or perhaps tomorrow morning. I need to rebase them, do a quick sanity > check and then they should be ready to go.
Thanks! Looking forward to it. > > I had been waiting for the resolution of the Debian packaging issue > and see that Frode has addressed that in his series of patches. > Thank you Frode! > > - Greg _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
