| Message ID | 20220415214245.18948-1-gvrose8192@gmail.com |
|---|---|
| Headers | show |
| Series | Remove OVS kernel driver | expand |
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? Thanks, - Greg > > Greg Rose (6): > acinclude.m4: Remove support for building the OVS kernel module > rhel: Remove kernel mode spec > rhel: Remove RHEL 6 kernel module spec > tests: Remove support for check-kmod test > Documentation: Remove kernel module documentation > Disable unsupported kernel builds > > .github/workflows/build-and-test.yml | 35 - > Documentation/faq/releases.rst | 5 +- > .../contributing/backporting-patches.rst | 7 + > Documentation/intro/install/fedora.rst | 24 - > Documentation/intro/install/general.rst | 63 -- > acinclude.m4 | 683 +----------------- > rhel/automake.mk | 17 - > rhel/kmod-openvswitch-rhel6.spec.in | 123 ---- > rhel/openvswitch-kmod-fedora.spec.in | 152 ---- > tests/automake.mk | 6 - > 10 files changed, 11 insertions(+), 1104 deletions(-) > delete mode 100644 rhel/kmod-openvswitch-rhel6.spec.in > delete mode 100644 rhel/openvswitch-kmod-fedora.spec.in >
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? > > Thanks, > > - Greg > > >> >> Greg Rose (6): >> acinclude.m4: Remove support for building the OVS kernel module >> rhel: Remove kernel mode spec >> rhel: Remove RHEL 6 kernel module spec >> tests: Remove support for check-kmod test >> Documentation: Remove kernel module documentation >> Disable unsupported kernel builds >> >> .github/workflows/build-and-test.yml | 35 - >> Documentation/faq/releases.rst | 5 +- >> .../contributing/backporting-patches.rst | 7 + >> Documentation/intro/install/fedora.rst | 24 - >> Documentation/intro/install/general.rst | 63 -- >> acinclude.m4 | 683 +----------------- >> rhel/automake.mk | 17 - >> rhel/kmod-openvswitch-rhel6.spec.in | 123 ---- >> rhel/openvswitch-kmod-fedora.spec.in | 152 ---- >> tests/automake.mk | 6 - >> 10 files changed, 11 insertions(+), 1104 deletions(-) >> delete mode 100644 rhel/kmod-openvswitch-rhel6.spec.in >> delete mode 100644 rhel/openvswitch-kmod-fedora.spec.in >> > _______________________________________________ > dev mailing list > dev@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev >
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
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? Thanks, - Greg
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. Best regards, Ilya Maximets.
On Tue, May 31, 2022 at 7:05 PM Ilya Maximets <i.maximets@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.
On 5/31/2022 12:22 PM, Frode Nordahl wrote: > On Tue, May 31, 2022 at 7:05 PM Ilya Maximets <i.maximets@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. Thanks, - Greg
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.maximets@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. 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! 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? Best regards, Ilya Maximets.
On Thu, Jun 2, 2022 at 6:58 PM Ilya Maximets <i.maximets@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.maximets@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
On Fri, Jun 3, 2022 at 4:16 PM Frode Nordahl <frode.nordahl@canonical.com> wrote: > > On Thu, Jun 2, 2022 at 6:58 PM Ilya Maximets <i.maximets@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.maximets@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?
On 6/10/22 02:31, Frode Nordahl wrote: > On Fri, Jun 3, 2022 at 4:16 PM Frode Nordahl > <frode.nordahl@canonical.com> wrote: >> >> On Thu, Jun 2, 2022 at 6:58 PM Ilya Maximets <i.maximets@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.maximets@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.
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.nordahl@canonical.com> wrote: >>> >>> On Thu, Jun 2, 2022 at 6:58 PM Ilya Maximets <i.maximets@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.maximets@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. 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
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.nordahl@canonical.com> wrote: >>>> >>>> On Thu, Jun 2, 2022 at 6:58 PM Ilya Maximets <i.maximets@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.maximets@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