Community CI Meeting Minutes - January 18, 2024

Community CI Meeting Minutes - January 18, 2024

[Patrick Robb]

[-- Attachment #1: Type: text/plain, Size: 7051 bytes --]

January 18, 2024

#####################################################################
Attendees
1. Lincoln Lavoie
2. Thomas Monjalon
3. Aaron Conole
4. Jeremy Spewock
5. Paul Szczepanek
6. Ali Alnubani
7. Juraj Linkeš

#####################################################################
Minutes

=====================================================================
General Announcements
* First 2024 DTS WG meeting was held yesterday, and the minutes are here:
https://docs.google.com/document/d/1pG_NGuwYgPuovwIfhvcs9u8PNYIJuInsFr0GeTUIU4k/edit?usp=sharing
   * Patrick Robb will publish the meeting minutes

=====================================================================
CI Status

---------------------------------------------------------------------
UNH-IOL Community Lab
* Octeon CN106XX: Patrick worked with Hiral this week about the process for
SDK rebuild. This will have to happen regularly, but we now have a VM setup
which will serve as the place to rebuild SDK and act as TFTP server for the
Octeon board.
   * After that we need to iron out switching rootfs to ubuntu, setting up
DTS on the tester, validating this works fine in a CI context (Phanendra
from Marvell has approved of the concept).
* The Intel server arrived in the mail yesterday. We will mount the system
this week and begin setup. As a reminder this now unblocks:
   * E810 testing for Intel
   * Traffic gen for the CX7 testing (this server will act as TG)
   * Traffic gen for the Octeon CN106xx board
* The new create dpdk artifact for ci testing script is in production at
UNH, and Adam is submitting the V3 patchseries for this to dpdk-ci today
* There is an update from the patchwork maintainer about supporting
Depends-on via patchwork. I encourage everyone to read his full thoughts on
the issue below, but shorthand conclusions are:
   * He prefers to only support Depends-on on a series basis, not a series
or patch basis.
      * Patrick will update the CI testing thread on this topic, but this
may require the DPDK community agreeing to a new approach. From looking
through the dev mailing list, it seems that series dependency is the
typical use, but there are also some examples of developers using patch
dependency.
      * Keep the same syntax which allows for depends-on: patch, but in
reality translate this to depends on that patch’s series
   * He will need some help for the effort. We can ping the DPDK community
to look for volunteers. Or, it can possibly become a community ask for
development at the DPDK Community Lab. Looking at it at a high level I
don’t think the scope will be too bad.
   * Full thread: https://github.com/getpatchwork/git-pw/issues/71
* Arm-Ampere still needs a kernel rebuild for the QAT card
* Standing up ts-factory testing framework
   * Adam did the first cx-5 run on an ARM system, and will do an Intel
XL710 run on an ARM system today. Both will be published on Oktet Lab’s
Bublik for review.
   * Unlike our ARM testbeds, our x86 servers are single server TG/DUT
testbeds, which breaks an assumption in ts-factory. My view on how to
proceed is bring testing online with what works now (arm), then review the
value with the community, and choose a strategy for x86 based on what we
learn from running this at the lab.
   * Andrew from Oktet labs has added some missing components to GitHub for
the data visualization tool (Bublik), and has finished categorizing the
tests for the XL710 and the expected results for that NIC
* Old DTS patches:
   * We noticed that as DPDK has grown, the compile time also increases and
the old compile timeout for the DUT is no longer valid on some slower
systems. Jeremy will submit a patch extending the timeout.
   * Once the cx7 is online, patrick will submit the patch adding the cx6
and cx7 to the NIC registry in DTS
* Lincoln saw the email thread about DPDK failing to build on FreeBSD 14.
We are only testing FreeBSD 13 in the lab right now, so we will add
coverage for 14.

---------------------------------------------------------------------
Intel Lab
* John says there is still no new person who can act as a contact. There
have been further staffing changes at Intel, so it may be hard to get a
contact soon, but Patrick will keep asking.

---------------------------------------------------------------------
Github Actions
* Cirrus CI: Adding support for this to the 0 day robot. Aaron submitted a
patch for polling for Cirrus ci status in ovs.
* They are getting a server to migrate the VM over to, so there should be
minimal downtime associated with the hardware moving from Westford to
another state.

---------------------------------------------------------------------
Loongarch Lab
* None

=====================================================================
DTS Improvements & Test Development
* scapy/templated yaml for tests:
   * One motivation is for making writing simple tests in minimal time
(like 3 minutes). Should we aim for a target of writing a testsuite in
minutes, not hours?
   * Testing is broken down into phases, and you simply write in the raw
scapy commands or values to pass to testpmd
   * At the end, compare output string to an expected output string written
in the YAML
   * Is it possible to get the best of both worlds? We can try to remain
with python only, but use python annotations and assign python to TG, DUT
commands etc.
   * Gregory also splits the configuration of platform and test
configuration.
   * We should draw up a “pseudo” version of this structured test setup via
python, and review as a group
      * If we can draw this up we can compare against a currently written
test (like Jeremy’s scatter test), and then we will have a practical
example of the effort difference between the two approaches.
      * The API will evolve over time - for drawing up an example, we can
make up whatever we want
   * By using a templating system (or some python “syntactic sugar”), we
may remove some of the boilerplate overhead form writing a suite - possibly
a major value for making writing testsuites easier.
   * Obviously this all needs to be documented.
   * Paul: It may be a good approach to have a few more people write at
least one testsuite according to the current approach. Then, we use these
new tests to guide the creation of the “new” approach. Hopefully we learn
what works, what needs to be improved and refactored out into the framework
- pre-proving the validity of the new approach.
   * All DTS people will try to workshop next week to investigate what a
new approach would look like in concrete terms.
   * DTS group will go through all the new Bugzilla tickets at the next DTS
meeting.
      * Jeremy has volunteered to at least one during this release:
      * https://bugs.dpdk.org/show_bug.cgi?id=1359

=====================================================================
Any other business
* Next Meeting: February 1, 2024

[-- Attachment #2: Type: text/html, Size: 7507 bytes --]