Bug#974588: [ovs-dev] Bug#974588: openvswitch: DPDK 20.11 support and transition for bullseye
On Sat, 9 Jan 2021 at 21:20, Luca Boccassi wrote: > > On Sat, 9 Jan 2021 at 15:50, Luca Boccassi wrote: > > > > On Thu, 7 Jan 2021 at 20:14, Luca Boccassi wrote: > > > > > > On Thu, 7 Jan 2021 at 19:53, Thomas Goirand wrote: > > > > > > > > On 1/7/21 4:54 PM, Christian Ehrhardt wrote: > > > > > Hi, > > > > > as an FYI Ubuntu moved to recent commit def6eb1ea and for us it seems > > > > > to work fine so far. > > > > > See the package at: > > > > > https://launchpad.net/ubuntu/+source/openvswitch/2.15.0~git20210104.def6eb1ea-0ubuntu3 > > > > > > > > > > With that confirmed and the feature freeze coming soon. Would you mind > > > > > doing a similar upload to Debian-experimental soon'ish? > > > > > > > > So, basically, you wish that I package the tip of master in > > > > Experimental? I'll see if I find the time to do it. However, I very much > > > > would prefer if upstream OVS could cut a (alpha / beta) tag. > > > > > > > > Cheers, > > > > > > > > Thomas Goirand (zigo) > > > > > > Yes, given time is running out we need to get the transition starting > > > ASAP, unfortunately. The upstream OVS timeline for RCs and releases > > > unfortunately doesn't quite align and would be too late. I asked the > > > release team for an exception but I had no answer, so at this point it > > > seems to me the safest course of action is to assume we're not getting > > > one. > > > > > > There has been extensive testing of that commit id by Canonical, so it > > > should be safe to use in unstable/testing for a month, until the > > > proper release. > > > > > > Thank you! > > > > > > Kind regards, > > > Luca Boccassi > > > > Hello Thomas, > > > > I've prepared an MR: > > https://salsa.debian.org/openstack-team/third-party/openvswitch/-/merge_requests/6 > > > > The changes look quite simple and they are based on the Ubuntu > > package. Exact same upstream snapshot is used, so that we know it's > > been tested. I have build-tested it in a chroot with libdpdk-dev from > > experimental. > > > > Please, can we get this sorted soon? Would you be OK with an NMU to > > experimental? > > > > Thank you! > > > > Kind regards, > > Luca Boccassi > > Christian, > > We've got tons of test failures with a merge of the same commit. Any > idea? 586 tests are failing out of 2266... My bad, I had missed this commit: https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/openvswitch/commit/?id=b50073a199c3d7ca44425f42282a76ce1ef31873 Updated the MR on Salsa. Kind regards, Luca Boccassi
Bug#974588: [ovs-dev] Bug#974588: openvswitch: DPDK 20.11 support and transition for bullseye
On Sat, 9 Jan 2021 at 15:50, Luca Boccassi wrote: > > On Thu, 7 Jan 2021 at 20:14, Luca Boccassi wrote: > > > > On Thu, 7 Jan 2021 at 19:53, Thomas Goirand wrote: > > > > > > On 1/7/21 4:54 PM, Christian Ehrhardt wrote: > > > > Hi, > > > > as an FYI Ubuntu moved to recent commit def6eb1ea and for us it seems > > > > to work fine so far. > > > > See the package at: > > > > https://launchpad.net/ubuntu/+source/openvswitch/2.15.0~git20210104.def6eb1ea-0ubuntu3 > > > > > > > > With that confirmed and the feature freeze coming soon. Would you mind > > > > doing a similar upload to Debian-experimental soon'ish? > > > > > > So, basically, you wish that I package the tip of master in > > > Experimental? I'll see if I find the time to do it. However, I very much > > > would prefer if upstream OVS could cut a (alpha / beta) tag. > > > > > > Cheers, > > > > > > Thomas Goirand (zigo) > > > > Yes, given time is running out we need to get the transition starting > > ASAP, unfortunately. The upstream OVS timeline for RCs and releases > > unfortunately doesn't quite align and would be too late. I asked the > > release team for an exception but I had no answer, so at this point it > > seems to me the safest course of action is to assume we're not getting > > one. > > > > There has been extensive testing of that commit id by Canonical, so it > > should be safe to use in unstable/testing for a month, until the > > proper release. > > > > Thank you! > > > > Kind regards, > > Luca Boccassi > > Hello Thomas, > > I've prepared an MR: > https://salsa.debian.org/openstack-team/third-party/openvswitch/-/merge_requests/6 > > The changes look quite simple and they are based on the Ubuntu > package. Exact same upstream snapshot is used, so that we know it's > been tested. I have build-tested it in a chroot with libdpdk-dev from > experimental. > > Please, can we get this sorted soon? Would you be OK with an NMU to > experimental? > > Thank you! > > Kind regards, > Luca Boccassi Christian, We've got tons of test failures with a merge of the same commit. Any idea? 586 tests are failing out of 2266...
Bug#974588: [ovs-dev] Bug#974588: openvswitch: DPDK 20.11 support and transition for bullseye
On Thu, 7 Jan 2021 at 20:14, Luca Boccassi wrote: > > On Thu, 7 Jan 2021 at 19:53, Thomas Goirand wrote: > > > > On 1/7/21 4:54 PM, Christian Ehrhardt wrote: > > > Hi, > > > as an FYI Ubuntu moved to recent commit def6eb1ea and for us it seems > > > to work fine so far. > > > See the package at: > > > https://launchpad.net/ubuntu/+source/openvswitch/2.15.0~git20210104.def6eb1ea-0ubuntu3 > > > > > > With that confirmed and the feature freeze coming soon. Would you mind > > > doing a similar upload to Debian-experimental soon'ish? > > > > So, basically, you wish that I package the tip of master in > > Experimental? I'll see if I find the time to do it. However, I very much > > would prefer if upstream OVS could cut a (alpha / beta) tag. > > > > Cheers, > > > > Thomas Goirand (zigo) > > Yes, given time is running out we need to get the transition starting > ASAP, unfortunately. The upstream OVS timeline for RCs and releases > unfortunately doesn't quite align and would be too late. I asked the > release team for an exception but I had no answer, so at this point it > seems to me the safest course of action is to assume we're not getting > one. > > There has been extensive testing of that commit id by Canonical, so it > should be safe to use in unstable/testing for a month, until the > proper release. > > Thank you! > > Kind regards, > Luca Boccassi Hello Thomas, I've prepared an MR: https://salsa.debian.org/openstack-team/third-party/openvswitch/-/merge_requests/6 The changes look quite simple and they are based on the Ubuntu package. Exact same upstream snapshot is used, so that we know it's been tested. I have build-tested it in a chroot with libdpdk-dev from experimental. Please, can we get this sorted soon? Would you be OK with an NMU to experimental? Thank you! Kind regards, Luca Boccassi
Bug#974588: [ovs-dev] Bug#974588: openvswitch: DPDK 20.11 support and transition for bullseye
On Thu, Jan 7, 2021 at 5:04 PM Stokes, Ian wrote: > > > On Thu, Nov 19, 2020 at 5:12 PM Stokes, Ian wrote: > > > > > > > > I proposed an earlier upload from git as a temporary measure to ease > > > > > the ABI transition. I worry that an ABI transition 2 months after the > > > > > transition freeze is too much to ask, even if it only affects > > > > > src:openvswitch (and src:collectd, but that's a straightforward > > > > > rebuild, no changes needed). > > > > > Nonetheless, let's see if the release team considers this acceptable. > > > > > > > > Two things worth mentioning: > > > > 1. We will have support for DPDK 20.11 in OVS by next week by Ian Stokes > > > > This was already validated vs 20.11-rc4 > > > > > > Hi Christian, > > > > > > Just to clarify this, I think we will have an RFC patch to support DPDK > > > 20.11 > > with OVS master by either tomorrow or early next week. We are just waiting > > on review of the patch below > > > > > > > > http://patchwork.ozlabs.org/project/openvswitch/patch/20201119123554.44 > > 684-1-sunil.pa...@intel.com/ > > > > > > But just to clarify, once I release the RFC patch that does not mean it > > > will be > > up streamed immediately to OVS master, just that it will be available for > > review by the community at that stage. > > > > > > Support for DPDK 20.11 in OVS master will not be available until the > > community has signed off on the patch itself (which may require patch > > revisions), this may take longer than next week. > > > > Hi, > > as an FYI Ubuntu moved to recent commit def6eb1ea and for us it seems > > to work fine so far. > > See the package at: > > https://launchpad.net/ubuntu/+source/openvswitch/2.15.0~git20210104.de > > f6eb1ea-0ubuntu3 > > > > With that confirmed and the feature freeze coming soon. Would you mind > > doing a similar upload to Debian-experimental soon'ish? > > > > Hi Christian, not sure if that was targeted to myself? Hi Ian o/, it was mostly for the discussion about when/how to carve out a first OVS 2.15 to be in time for the Debian Feature Freeze. Ubuntu is in the same situation every spring (overlapping release dates) - so I shared before that this worked well for us in the past - and also this time seems to work well. > As an FYI OVS master now supports DPDK 20.11 as of the following commit. > > 252e1e576443 ("dpdk: Update to use DPDK v20.11.") Yeah I know, we've taken a slightly later commit (in case there would have been follow up fixes) and things seem fine for now. We will (as usual) before the final release then update to the latest and then final 2.15. > Regards > Ian > > > > Regards > > > Ian > > > > > > > > > > > > -- > > Christian Ehrhardt > > Staff Engineer, Ubuntu Server > > Canonical Ltd -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#974588: [ovs-dev] Bug#974588: openvswitch: DPDK 20.11 support and transition for bullseye
On Thu, 7 Jan 2021 at 19:53, Thomas Goirand wrote: > > On 1/7/21 4:54 PM, Christian Ehrhardt wrote: > > Hi, > > as an FYI Ubuntu moved to recent commit def6eb1ea and for us it seems > > to work fine so far. > > See the package at: > > https://launchpad.net/ubuntu/+source/openvswitch/2.15.0~git20210104.def6eb1ea-0ubuntu3 > > > > With that confirmed and the feature freeze coming soon. Would you mind > > doing a similar upload to Debian-experimental soon'ish? > > So, basically, you wish that I package the tip of master in > Experimental? I'll see if I find the time to do it. However, I very much > would prefer if upstream OVS could cut a (alpha / beta) tag. > > Cheers, > > Thomas Goirand (zigo) Yes, given time is running out we need to get the transition starting ASAP, unfortunately. The upstream OVS timeline for RCs and releases unfortunately doesn't quite align and would be too late. I asked the release team for an exception but I had no answer, so at this point it seems to me the safest course of action is to assume we're not getting one. There has been extensive testing of that commit id by Canonical, so it should be safe to use in unstable/testing for a month, until the proper release. Thank you! Kind regards, Luca Boccassi
Bug#974588: [ovs-dev] Bug#974588: openvswitch: DPDK 20.11 support and transition for bullseye
On 1/7/21 4:54 PM, Christian Ehrhardt wrote: > Hi, > as an FYI Ubuntu moved to recent commit def6eb1ea and for us it seems > to work fine so far. > See the package at: > https://launchpad.net/ubuntu/+source/openvswitch/2.15.0~git20210104.def6eb1ea-0ubuntu3 > > With that confirmed and the feature freeze coming soon. Would you mind > doing a similar upload to Debian-experimental soon'ish? So, basically, you wish that I package the tip of master in Experimental? I'll see if I find the time to do it. However, I very much would prefer if upstream OVS could cut a (alpha / beta) tag. Cheers, Thomas Goirand (zigo)
Bug#974588: [ovs-dev] Bug#974588: openvswitch: DPDK 20.11 support and transition for bullseye
> On Thu, Nov 19, 2020 at 5:12 PM Stokes, Ian wrote: > > > > > > I proposed an earlier upload from git as a temporary measure to ease > > > > the ABI transition. I worry that an ABI transition 2 months after the > > > > transition freeze is too much to ask, even if it only affects > > > > src:openvswitch (and src:collectd, but that's a straightforward > > > > rebuild, no changes needed). > > > > Nonetheless, let's see if the release team considers this acceptable. > > > > > > Two things worth mentioning: > > > 1. We will have support for DPDK 20.11 in OVS by next week by Ian Stokes > > > This was already validated vs 20.11-rc4 > > > > Hi Christian, > > > > Just to clarify this, I think we will have an RFC patch to support DPDK > > 20.11 > with OVS master by either tomorrow or early next week. We are just waiting > on review of the patch below > > > > > http://patchwork.ozlabs.org/project/openvswitch/patch/20201119123554.44 > 684-1-sunil.pa...@intel.com/ > > > > But just to clarify, once I release the RFC patch that does not mean it > > will be > up streamed immediately to OVS master, just that it will be available for > review by the community at that stage. > > > > Support for DPDK 20.11 in OVS master will not be available until the > community has signed off on the patch itself (which may require patch > revisions), this may take longer than next week. > > Hi, > as an FYI Ubuntu moved to recent commit def6eb1ea and for us it seems > to work fine so far. > See the package at: > https://launchpad.net/ubuntu/+source/openvswitch/2.15.0~git20210104.de > f6eb1ea-0ubuntu3 > > With that confirmed and the feature freeze coming soon. Would you mind > doing a similar upload to Debian-experimental soon'ish? > Hi Christian, not sure if that was targeted to myself? As an FYI OVS master now supports DPDK 20.11 as of the following commit. 252e1e576443 ("dpdk: Update to use DPDK v20.11.") Regards Ian > > Regards > > Ian > > > > > > > -- > Christian Ehrhardt > Staff Engineer, Ubuntu Server > Canonical Ltd
Bug#974588: [ovs-dev] Bug#974588: openvswitch: DPDK 20.11 support and transition for bullseye
On Thu, Nov 19, 2020 at 5:12 PM Stokes, Ian wrote: > > > > I proposed an earlier upload from git as a temporary measure to ease > > > the ABI transition. I worry that an ABI transition 2 months after the > > > transition freeze is too much to ask, even if it only affects > > > src:openvswitch (and src:collectd, but that's a straightforward > > > rebuild, no changes needed). > > > Nonetheless, let's see if the release team considers this acceptable. > > > > Two things worth mentioning: > > 1. We will have support for DPDK 20.11 in OVS by next week by Ian Stokes > > This was already validated vs 20.11-rc4 > > Hi Christian, > > Just to clarify this, I think we will have an RFC patch to support DPDK > 20.11 with OVS master by either tomorrow or early next week. We are just > waiting on review of the patch below > > http://patchwork.ozlabs.org/project/openvswitch/patch/20201119123554.44684-1-sunil.pa...@intel.com/ > > But just to clarify, once I release the RFC patch that does not mean it will > be up streamed immediately to OVS master, just that it will be available for > review by the community at that stage. > > Support for DPDK 20.11 in OVS master will not be available until the > community has signed off on the patch itself (which may require patch > revisions), this may take longer than next week. Hi, as an FYI Ubuntu moved to recent commit def6eb1ea and for us it seems to work fine so far. See the package at: https://launchpad.net/ubuntu/+source/openvswitch/2.15.0~git20210104.def6eb1ea-0ubuntu3 With that confirmed and the feature freeze coming soon. Would you mind doing a similar upload to Debian-experimental soon'ish? > Regards > Ian > > -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#974588: [ovs-dev] Bug#974588: openvswitch: DPDK 20.11 support and transition for bullseye
> > I proposed an earlier upload from git as a temporary measure to ease > > the ABI transition. I worry that an ABI transition 2 months after the > > transition freeze is too much to ask, even if it only affects > > src:openvswitch (and src:collectd, but that's a straightforward > > rebuild, no changes needed). > > Nonetheless, let's see if the release team considers this acceptable. > > Two things worth mentioning: > 1. We will have support for DPDK 20.11 in OVS by next week by Ian Stokes > This was already validated vs 20.11-rc4 Hi Christian, Just to clarify this, I think we will have an RFC patch to support DPDK 20.11 with OVS master by either tomorrow or early next week. We are just waiting on review of the patch below http://patchwork.ozlabs.org/project/openvswitch/patch/20201119123554.44684-1-sunil.pa...@intel.com/ But just to clarify, once I release the RFC patch that does not mean it will be up streamed immediately to OVS master, just that it will be available for review by the community at that stage. Support for DPDK 20.11 in OVS master will not be available until the community has signed off on the patch itself (which may require patch revisions), this may take longer than next week. Regards Ian
Bug#974588: [ovs-dev] Bug#974588: openvswitch: DPDK 20.11 support and transition for bullseye
On 11/13/20 11:46 PM, Thomas Goirand wrote: > On 11/13/20 6:54 PM, Ilya Maximets wrote: >> On 11/13/20 1:47 PM, Thomas Goirand wrote: >>> On 11/12/20 5:09 PM, Luca Boccassi wrote: Source: openvswitch Version: 2.13.0+dfsg1-12 Severity: normal X-Debbugs-CC: pkg-dpdk-de...@lists.alioth.debian.org christian.ehrha...@canonical.com Tags: bullseye Dear Openvswitch Maintainers, >> >> Hi, Luca and Thomas. >> We are scoping the src:dpdk 19.11 -> 20.11 transition. If possible, we'd really like to go to bullseye with the latest upstream LTS, as 19.11 is EOL at the end of next year. OVS support for DPDK 20.11 will be released upstream in v2.15, which is due for release on February 15 [1]. Bullseye transition freeze is on January 12 [2], so the dates don't align very well. >> >> >From the upstream OVS perspective feature freeze usually happens on >> January 15. After this point only bug fixes (under normal conditions) >> could be accepted. Unfortunately, as it always happens, last few days >> before the feature freeze might be hot in terms of accepting big number >> of new features. We could try adjusting these dates if January 12 is >> a critical hard deadline, so the feature-list will be stable to the date. >> Let me now if you need this kind of measures from the upstream OVS. >> We can discuss. >> So we are looking to formulate a plan that you can agree with, to sort this out. Based on experience, what Ubuntu usually does to meet release deadlines is to upload from git earlier than the release, so that all major incompatibilities can be sorted. And then after the freeze, once the release is officially out, do a final upgrade to the released version - since a similar enough version was uploaded from git, and at the end of a release cycle it's mostly bug fixes that land upstream, such an upload is acceptable. So we'd like to propose the following ideas: - between now and December: upload v2.14, to minimize the later jump - by the first week of January: upload 2.15~git from the tip of the master branch to experimental - stabilize and sort eventual build issues - upload dpdk 20.11 and ovs 2.15~git to unstable - upload 2.15 proper in February as a bug fix upload to unstable What do you think? Does this sound like a workable plan? We are of course happy to help - Ubuntu will go through the exact same process for 21.04, so a lot of the work is "shared". Thank you! >>> >>> Hi Luca, >>> >>> I wouldn't mind going for this kind of plan, however, I would really not >>> like uploading a version which isn't final from the upstream point of >>> view. So we would have to get the release team approve for a late upload >>> of OVS 2.15. Note that I'm really not happy with the current state of >>> OVS in Buster, which isn't usable right now (I've been using the tip of >>> the git branch for 2.10.0 in production, not what's in Buster that often >>> crashes). I don't want this to happen again. >>> >>> Please get the release team in the loop, therefore, and make them >>> pre-approve such a plan, by opening a bug with them. >>> >>> Also, I would very much like to have OVS and OVN being packaged and >>> maintained on both Ubuntu and Debian the same way. I would very much >>> like if this could happen, because maintaining OVS is hard, and I really >>> feel alone doing it. Your thoughts? >> >> I'm not very familiar with debian/ubuntu packaging process for OVS and OVN, >> but if there is something that we can do from the upstream side to help, e.g. >> by accepting some patches or streamlining release processes, let me know. >> We clearly have a communication gap between upstream OVS and maintainers of >> packages in distributions. >> >> Best regards, Ilya Maximets. > > Hi Ilya, > > Thanks for getting involved in the discussion. > > What I'm worried, is if somehow, the latest OVS breaks OpenStack > Victoria, which will be the OpenStack release for Bullseye. Can you > assure me that it wont break it? I don't think that we have any destructive/incompatible changes planned. Also, IIRC, upstream OpenStack CI had a job to test with OVS master branch (I need to recheck that). So, I hope that we could catch issues early, if any. Best regards, Ilya Maximets.
Bug#974588: [ovs-dev] Bug#974588: openvswitch: DPDK 20.11 support and transition for bullseye
On 11/13/20 6:54 PM, Ilya Maximets wrote: > On 11/13/20 1:47 PM, Thomas Goirand wrote: >> On 11/12/20 5:09 PM, Luca Boccassi wrote: >>> Source: openvswitch >>> Version: 2.13.0+dfsg1-12 >>> Severity: normal >>> X-Debbugs-CC: pkg-dpdk-de...@lists.alioth.debian.org >>> christian.ehrha...@canonical.com >>> Tags: bullseye >>> >>> Dear Openvswitch Maintainers, > > Hi, Luca and Thomas. > >>> >>> We are scoping the src:dpdk 19.11 -> 20.11 transition. If possible, >>> we'd really like to go to bullseye with the latest upstream LTS, as >>> 19.11 is EOL at the end of next year. >>> >>> OVS support for DPDK 20.11 will be released upstream in v2.15, which is >>> due for release on February 15 [1]. >>> Bullseye transition freeze is on January 12 [2], so the dates >>> don't align very well. > >>From the upstream OVS perspective feature freeze usually happens on > January 15. After this point only bug fixes (under normal conditions) > could be accepted. Unfortunately, as it always happens, last few days > before the feature freeze might be hot in terms of accepting big number > of new features. We could try adjusting these dates if January 12 is > a critical hard deadline, so the feature-list will be stable to the date. > Let me now if you need this kind of measures from the upstream OVS. > We can discuss. > >>> >>> So we are looking to formulate a plan that you can agree with, to sort >>> this out. >>> >>> Based on experience, what Ubuntu usually does to meet release deadlines >>> is to upload from git earlier than the release, so that all major >>> incompatibilities can be sorted. And then after the freeze, once the >>> release is officially out, do a final upgrade to the released version - >>> since a similar enough version was uploaded from git, and at the end of >>> a release cycle it's mostly bug fixes that land upstream, such an >>> upload is acceptable. >>> >>> So we'd like to propose the following ideas: >>> >>> - between now and December: upload v2.14, to minimize the later jump >>> - by the first week of January: upload 2.15~git from the tip of the >>> master branch to experimental >>> - stabilize and sort eventual build issues >>> - upload dpdk 20.11 and ovs 2.15~git to unstable >>> - upload 2.15 proper in February as a bug fix upload to unstable >>> >>> What do you think? Does this sound like a workable plan? >>> >>> We are of course happy to help - Ubuntu will go through the exact same >>> process for 21.04, so a lot of the work is "shared". >>> >>> Thank you! >> >> Hi Luca, >> >> I wouldn't mind going for this kind of plan, however, I would really not >> like uploading a version which isn't final from the upstream point of >> view. So we would have to get the release team approve for a late upload >> of OVS 2.15. Note that I'm really not happy with the current state of >> OVS in Buster, which isn't usable right now (I've been using the tip of >> the git branch for 2.10.0 in production, not what's in Buster that often >> crashes). I don't want this to happen again. >> >> Please get the release team in the loop, therefore, and make them >> pre-approve such a plan, by opening a bug with them. >> >> Also, I would very much like to have OVS and OVN being packaged and >> maintained on both Ubuntu and Debian the same way. I would very much >> like if this could happen, because maintaining OVS is hard, and I really >> feel alone doing it. Your thoughts? > > I'm not very familiar with debian/ubuntu packaging process for OVS and OVN, > but if there is something that we can do from the upstream side to help, e.g. > by accepting some patches or streamlining release processes, let me know. > We clearly have a communication gap between upstream OVS and maintainers of > packages in distributions. > > Best regards, Ilya Maximets. Hi Ilya, Thanks for getting involved in the discussion. What I'm worried, is if somehow, the latest OVS breaks OpenStack Victoria, which will be the OpenStack release for Bullseye. Can you assure me that it wont break it? Cheers, Thomas Goirand (zigo)
Bug#974588: [ovs-dev] Bug#974588: openvswitch: DPDK 20.11 support and transition for bullseye
On 11/13/20 1:47 PM, Thomas Goirand wrote: > On 11/12/20 5:09 PM, Luca Boccassi wrote: >> Source: openvswitch >> Version: 2.13.0+dfsg1-12 >> Severity: normal >> X-Debbugs-CC: pkg-dpdk-de...@lists.alioth.debian.org >> christian.ehrha...@canonical.com >> Tags: bullseye >> >> Dear Openvswitch Maintainers, Hi, Luca and Thomas. >> >> We are scoping the src:dpdk 19.11 -> 20.11 transition. If possible, >> we'd really like to go to bullseye with the latest upstream LTS, as >> 19.11 is EOL at the end of next year. >> >> OVS support for DPDK 20.11 will be released upstream in v2.15, which is >> due for release on February 15 [1]. >> Bullseye transition freeze is on January 12 [2], so the dates >> don't align very well. >From the upstream OVS perspective feature freeze usually happens on January 15. After this point only bug fixes (under normal conditions) could be accepted. Unfortunately, as it always happens, last few days before the feature freeze might be hot in terms of accepting big number of new features. We could try adjusting these dates if January 12 is a critical hard deadline, so the feature-list will be stable to the date. Let me now if you need this kind of measures from the upstream OVS. We can discuss. >> >> So we are looking to formulate a plan that you can agree with, to sort >> this out. >> >> Based on experience, what Ubuntu usually does to meet release deadlines >> is to upload from git earlier than the release, so that all major >> incompatibilities can be sorted. And then after the freeze, once the >> release is officially out, do a final upgrade to the released version - >> since a similar enough version was uploaded from git, and at the end of >> a release cycle it's mostly bug fixes that land upstream, such an >> upload is acceptable. >> >> So we'd like to propose the following ideas: >> >> - between now and December: upload v2.14, to minimize the later jump >> - by the first week of January: upload 2.15~git from the tip of the >> master branch to experimental >> - stabilize and sort eventual build issues >> - upload dpdk 20.11 and ovs 2.15~git to unstable >> - upload 2.15 proper in February as a bug fix upload to unstable >> >> What do you think? Does this sound like a workable plan? >> >> We are of course happy to help - Ubuntu will go through the exact same >> process for 21.04, so a lot of the work is "shared". >> >> Thank you! > > Hi Luca, > > I wouldn't mind going for this kind of plan, however, I would really not > like uploading a version which isn't final from the upstream point of > view. So we would have to get the release team approve for a late upload > of OVS 2.15. Note that I'm really not happy with the current state of > OVS in Buster, which isn't usable right now (I've been using the tip of > the git branch for 2.10.0 in production, not what's in Buster that often > crashes). I don't want this to happen again. > > Please get the release team in the loop, therefore, and make them > pre-approve such a plan, by opening a bug with them. > > Also, I would very much like to have OVS and OVN being packaged and > maintained on both Ubuntu and Debian the same way. I would very much > like if this could happen, because maintaining OVS is hard, and I really > feel alone doing it. Your thoughts? I'm not very familiar with debian/ubuntu packaging process for OVS and OVN, but if there is something that we can do from the upstream side to help, e.g. by accepting some patches or streamlining release processes, let me know. We clearly have a communication gap between upstream OVS and maintainers of packages in distributions. Best regards, Ilya Maximets.