Community CI Meeting Minutes - December 21, 2023

Community CI Meeting Minutes - December 21, 2023

[Patrick Robb]

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

December 21, 2023

#####################################################################
Attendees
1. Patrick Robb
2. Paul
3. Juraj Linkeš
4. Thomas Monjalon
5. David Marchand
6. Lincoln Lavoie

#####################################################################
Agenda
1. General Announcements
2. CI Status
3. DTS Improvements & Test Development
4. Any other business

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

=====================================================================
General Announcements
* Intel seems to be out of the picture for now, who's taking care of the
original DTS Patchwork https://patches.dpdk.org/project/dts/list/?
   * There are a lot of pending patches (74)
   * Most are from Intel, for Intel devices
   * Thomas will ping intel seeing if they have anyone who can get involved
in new DTS. If it’s possible for Intel to provide some reviews, we should
do a final phase of merging patches to old DTS (so the 74 patches submitted
now), and then direct all future efforts to new DTS and encourage Intel
people to move in that direction.
      * Lijuan Tu is definitely no longer at Intel as we got a bounce from
her email address

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

---------------------------------------------------------------------
UNH-IOL Community Lab
* Octeon board bringup is ongoing
* Windows testing: We received another request to extend windows test
coverage again, since initially setting up the Windows Server 2022 testbed
a few weeks ago. We will do thai work in January, and the new test coverage
for Windows Server 2022 will be like:
   * Windows Server 2022
      * mingw64 compile
      * dpdk unit tests
      * Clang/MSVC compile
      * MSVC meson compile (Developer Command Prompt for VS 2022 Preview)
* Apply patch and create DPDK artifact script: For CI testing stability
reasons, we are silently running this over Holiday break (so we are still
using the old script for now), and will switch over on January 2nd. That
means we are still hitting the dpdk.org git server for fetching changes for
the next couple weeks.
   * We will swap into production at UNH CI on Jan 2nd and then upstream to
dpdk-ci repo
* Intel QAT card (ARM Ampere Server)
   * Will rebuild the kernel in January
* Lincoln added a robots.txt to the site indicating to web crawlers not to
index the site for details pages
   * Amazon was hitting us, so Lincoln blocked the ip for their crawler
   * We also have a long term story for refactoring how we query our
database, as our test coverage grows

---------------------------------------------------------------------
Intel Lab
* Patrick pinged John McNamara for having the STV team using the GitHub
mirror, and he passed that message on.
   * Unfortunately, there is not yet another STV manager in place who can
act as a point of contact. Patrick will circle back on this in a couple
months and see if this has moved at all.

---------------------------------------------------------------------
Loongarch Lab
* Loongson was missing some patch emails because the parse-email.sh script
was not accounting for some cases where “Message ID” was lower cased. He
updated the regex for this and submitted the patch to dpdk-ci, which Aaron
has applied.

---------------------------------------------------------------------
Github Actions
* Has implemented email based retest request support
   * Aaron is submitting a dpdk-web patch updating the testing page on
dpdk.org, indicating that both IOL and Github Robot support this now

=====================================================================
DTS Improvements & Test Development
* Jeremy has submitted the Scattered Rx patch.
   * Jeremy tried to reply to existing patchseries, but might not have been
–in-reply-to the original cover letter
   * If he continues to have problems, will ping community
* Docstrings patch has been pushed, we need to rebase all our patches.
* DTS call on off-CI meeting weeks
   * Jeremy will share his schedule ASAP, and we will set the new regular
meeting time ASAP
   * What's the current schedule? Or rather, what will it be in the next
semester?
   * Invite Thomas to the call
   * Invite Gregory from nvidia. He has developed some testpmd python
scripts for testing - DTS should attempt to be simple and effective like
his scripts are.
* Next release cycle planning
   * Current patches:
      * Html docs from docstring generation
         * Where the docs should be stored or better yet, how should they
be accessed?
         * Currently we must first meet all python dependencies ahead of
producing docs via meson, but this is not ideal as Thomas wants to run it
for dpdk.org. This can live side by side with doxygen, but it needs to be
referenced properly, so a followup version is needed.
            * Will want to reference the new docs from the website
            * doc.dpdk.org/api
      * Scatter patch
      * Dockerfile patch
         * Created a ticket assigning this to Jeremy today
         * This one needs an owner; do we want to pursue this?
         * Dockerfile scales well for running in a lab context, and we want
the Dockerfile to be upstreamed so there can be community involvement
            * In the future, we could also publish the image to a public
repo which people could easily pull from
   * New patches:
      * Packet filtering capabilities
      * New unh developers will begin writing ethdev testsuites
      * RFC of blocked test cases with logging
         * Adds logging for if testcases are blocked by prereq steps
         * Renames dts.py to runner.py, brings some more logic into
runner.py
            * Jeremy will provide a review
      * Configuration: Would be nice to split configuration of machines
from configuration of the tests. Thomas is going to work on this some. Good
user experience is required in order to make DTS mandatory for developers.
         * Yaml schema: discusses some very old devices which can be
removed. This came from old DTS, because we couldn’t tell whether we would
need it or not, but we don’t.
      * A patch which updates licenses according to
https://matija.suklje.name/how-and-why-to-properly-write-copyright-statements-in-your-code#why-not-bump-the-year-on-change;
this is a suggestion from Thomas, do we need an RFC for this?
         * Copyright is valid for 50+ years, so that is enough time and we
don’t have to worry about bumping years in the license.
            * Juraj is going to ask in his company, because there are
different policies in USA, EU, etc.
      * Nothing else from me; also, I'm planning a month long vacation in
March - is that okay release-wise or should I move it?
      * Any other new patches? I suggest two approaches for new patches:
         * Identify a test suite and implement a bare minimum of what the
test suite needs
         * Identify features, discuss and implement those as deeply as
possible and add test cases to showcase the features. The features
may/should be based off of test suites
   * Planning thoughts/proposals:
      * We're doing last minute reviews and this time we even missed the
window
      * We're also doing last minute RFCs for the roadmap
      * Only add to roadmap the patches that we think will be ready for
review a month before the release (or mid-cycle or so)
         * If we can provide a rough roadmap for the entire calendar year,
we can start posting that now for 24.07, 24.11, etc. and then we get more
eyes on our goals
      * Reviews have the priority the month before the release; is nothing
to review, work on the next feature or test suite which will hopefully be
in an RFC state for the next roadmap
* The review process
   * We should strip/remove the text/code we're not commenting on in
review; it's much easier to review that way and the review history is much
cleaner
      * People may skip if they open an email is it’s 10 billon lines
   * How do we do a kind of "post merge review"? I have minor notes about
things that I'd like to refactor/change that I either didn't catch during
review or I've found a possibly better way; or I want to just refactor some
code from the original DTS that we didn't pay enough attention to before
(examples below)
      * Can we have a dedicated section for DTS calls in 2024 discussing
this? Patrick will add this to the Agenda, and we will go over all active
bugzilla tickets.
      * We can create a bugzilla page for tracking some small “bugs” like
this. Thomas made the project and is working on the correct bugzilla query.
* Major/important items for the future:
   * How do we decide when we want to update the required Python version?
      * 3.11 has StrEnum
      * 3.12 has @typing.override (useful for docs), but we can get that
with the typing_extensions module (but it doesn't work with Pylama due to a
bug)
   * Traffic filtering when capturing packets
   * Full duplex traffic support
   * Testbed capabilities for test case skipping
   * Port driver rebinding, the current implementation feels like a
workaround
   * Parallel functional testing, this is probably going to be relevant
when we have more suites
   * DTS general config file
      * Arbitrary network configuration like IP addresses common to all
tests and maybe other config, such that from cmdline args
   * Rename execution
   * Where should we put the different docs we have?
      * User, developer, api, test suite?
   * How to document test suites
      * The original DTS has extensive test plans, I'd like to use the
relevant information (big picture, config and test steps) in docstrings
   * Code restructuring, such as moving base classes
   * Multiple test cases in one
* Minor items for the future:
   * Do we want to enable pylint?
   * Fix the interactive session bug with the xmlrpc server and complete
the docstring
   * Context manager for testpmd, but probably for all interactive shells
   * Config improvements
      * Arch/OS discovery, remove unused, maybe more config validation
   * Paul mentioned logging improvements
      * Related to that is how do we want to use cmd history? If at all?
   * Bug: Framework cleanup before extraction fails due to root files
   * NIC configuration improvements - what do we need here (something like
NIC id)? this should be part of a patch which utilizes it
   * Improve statistics.txt
   * EAL/non-EAL parameters
      * Object for non-EAL params as well?
   * A lot of minor refactoring, in no particular order
      * Decoupling env vars and cmdline args parsing
      * Refactor _check_dts_python_version when updating Python version
      * Add references to parent configs in the config package
      * result.add_error(e) in _run_all_suites because of
BlockingTestSuiteError
      * Node shouldn't be ABC, same for InteractiveShell and revisit
InteractiveShell factory function (possibly split into methods)
      * What should skip-setup do?
      * Revisit set_up_execution, set_up_build_target (it should possibly
be in runner.py)
      * Add setters for SutNode.remote_dpdk_build_dir, SutNode.dpdk_version
and SutNode.get_build_target_info (or possibly combine)
      * Remote_session.name is used only in CommandResult, is that worth
it? Maybe we can use the logger instance for the same purpose
      * InteractiveShell.path should be @abstractproperty
      * OSSession.close should also close self.interactive_session
      * OSSession.get_dpdk_build_env_vars could be in build target config
      * OSSession.get_compiler_version should use config.Compiler
      * Should OSSession.get_compiler_version use the compiler enum?
      * Do we actually need PosixSession.get_dpdk_file_prefix?
      * Do we want to move Node connection to node outside __init__?
      * dts.rst tool documentation typo and omission (mypy)
      * Add coding guidelines

=====================================================================
Any other business
* Next meeting is January 4, and will be hosted by Lincoln
   * Juraj will be on vacation so likely will not be there
   * Thomas will be on vacation

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