Hello Christian! As per current policy (if I'm not mistaken), MREs for SRUs are now handled by the ubuntu-sru team [1], not the technical board. I can take a look at that tomorrow - could you draft an Ubuntu wiki page with this information in the meantime?
Cheers, [1] https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases On 14 December 2017 at 10:39, Christian Ehrhardt <[email protected]> wrote: > Hi Technical Board > > I'd like to apply for a Minor Release Exception for the DPDK package. > > If you want me to join a TB meeting please let me know, but I wanted > to give everyone the chance to read into the details before "just > showing up on the agenda". > > Background > - ---------- > > DPDK was included in Ubuntu main during the 16.04 release cycle; since > then upstream DPDK have started maintaining LTS releases of DPDK; > At least for our LTS releases we try to base on DPDK LTS releases > The first one was 16.11 which shipped in Zesty, and the next DPDK LTS > will be 17.11 which is our target for Ubuntu 18.04 Bionic Beaver. > > DPDK is a set of libraries and userspace drivers for fast packet > processing. It is designed to run on any processors. The first > supported CPU was Intel x86 and it is now extended to IBM POWER > and ARM. It runs mostly in Linux userland. > > Having a MRE for DPDK will ensure that users of DPDK receive timely > critical updates to this software. > > > Upstream Change and Release Policy > - ---------------------------------- > > Upstream have a policy [1] for accepting changes into the LTS release > branches which includes: > > - Back-porting of any critical bug fixes (crashes, data loss, etc) > - Minor usability items that are very low risk > - Only changes are backported that are part of the last main release > (This ensures more test coverage on those changes) > > There is a section on backporting features as well, but the > constraints limit it to something that is IMHO sane to SRU: > > - There is a justifiable use case (for example a new PMD). > - The change is non-invasive. > - There is support within the community. > > This so far happened very rarely and In addition those features > (mostly PMDs to support more HW) are only added in stable > releases being not built by default. For packaging that means > this is a no-op as we won't enable it so nothing changes. > > Commits are peer reviewed as part of the normal development process > and are signed to signify both the developer and review (see [2] for > the doc on this). > > LTS release updates are made after some time has passed (to allow > testing) and usually follow the new master release which happens > more or less every 3 months (see [3] for the current road-map). > > Updates to LTS releases are numbered with a minor point release > > 16.11: 16.11.1, 16.11.2, ... > 17.11: 17.11.1, 17.11.2, ... > > I watched the DPDK 16.11.x LTS release as it was the first of its > kind and it was great. Due to the fast pace of DPDK development with > 3 month release cycles a stable release is very important to carry > the stability needed by Distribution LTS releases. > Therefore I now plan to: > > - release Ubuntu 18.04 with the first stable release 17.11.1 > - Ask for this MRE to keep up with further stable releases > > > Upstream Regression Testing > - --------------------------- > > The upstream DPDK regression suite is a mix of comprehensive > functional tests (API coverage, etc.) and stress workloads via packet > generators. The full set is defined at [4]. > > The QA suite is run against the branches regularly to > hunt for low-frequency problems. Everything should be tested > regularly, and all but the most recent patches have been tested over > and extended period of time. > > Results are published via email to the dpdk-test-report mailing list > (see [5] for examples). > > In addition there is a smaller set of integration tests that runs > pre-checks. This is integrated into patchwork to directly augment > the patch review. > Those checks were run by Intel so far but are currently extended > to be a Hardware vendor opt-in to gain even more coverage - see [6] > for details on this growing part of the project that will provide > even more coverage. > > > Ubuntu DPDK Testing > - ------------------- > > DPDK has very high constraints on the environment (a lot of memory, > huge pages, certain CPU features) as well as the Hardware (limited > to a set of cards that have PMDs). > > Therefore we have a test [7] set outside of autopkgtest that tries to > cover the basic use case we know users have in mind (you can > use DPDK for way more, but we want and can only test what is in > the archive). > > In particular this sets up a set of KVM guests and runs a few test > tools to finally set up a dpdk enabled Open vSwitch between them. > On this dpdk enabled Open vSwitch it then runs some benchmarks to > ensure no significant performance loss (compared manually for now) > and some endurance tests via re-attaching devices or re-starting > guests (all those based on lessons learned by past issues we > identified). > > In addition, we set up autopkgtests [8] as well for those components > that can be tested. Those are mostly the extra packaging bits that > would not be covered by the upstream testing: > - testing the init scrips > - testing dkms modules work withing Ubuntu > - testing the correct linking of builds against dpdk > > Note: We also test the dpdk autotests in autopkgtests but for the > constraints mentioned before they are not reliable in the environment > they run in and thereby not yet gating. > > > Proposed SRU Approach > - --------------------- > > SRU updates for DPDK in Ubuntu will be aligned to the associated LTS > release of DPDK and only taken care for Ubuntu LTS releases: > > 18.04 -> DPDK 17.11.x > 20.04 -> DPDK 19.11.x (if releases still align) > [...] > > Ubuntu will only use the released version of updates and will not pull > directly from the upstream VCS. That is important as on the release of > a DPDK LTS there is another test/verification loop that we want to see > passed. > > Proposed packages will be prepared, uploaded and tested both > standalone and in-conjunction with Open vSwitch (following the > methodology detail above) as part of the standard SRU verification > process for packages with MRE's. > > I hope this information gives the technical board sufficient > confidence that DPDK is worthy of a minor release exception for SRU > activity. > > Thanks > > Christian > > [1]: http://dpdk.org/doc/guides/contributing/stable.html > [2]: http://dpdk.org/doc/guides/contributing/patches.html > [3]: http://dpdk.org/dev/roadmap > [4]: http://dpdk.org/doc/dts/gsg/intro.html > [5]: http://dpdk.org/ml/archives/test-report/2017-May/020337.html > [6]: http://dpdk.org/browse/tools/dpdk-ci/tree/README > [7]: > https://code.launchpad.net/~ubuntu-server/ubuntu/+source/dpdk-testing/+git/dpdk-testing > [8]: http://autopkgtest.ubuntu.com/packages/dpdk > > -- > Christian Ehrhardt > Software Engineer, Ubuntu Server > Canonical Ltd > > -- > technical-board mailing list > [email protected] > https://lists.ubuntu.com/mailman/listinfo/technical-board -- Łukasz 'sil2100' Zemczak Foundations Team [email protected] www.canonical.com -- technical-board mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/technical-board
