test suite reviews and discussions
 help / color / mirror / Atom feed
From: Patrick Robb <probb@iol.unh.edu>
To: ci@dpdk.org, dts@dpdk.org
Subject: Community CI Meeting Minutes - June 8, 2023
Date: Thu, 8 Jun 2023 10:13:10 -0400	[thread overview]
Message-ID: <CAJvnSUC1NpePoHvB+X9HfOVOtSwbGxgh927g-xFzUbdJr1qrSQ@mail.gmail.com> (raw)

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

June 8, 2023

#####################################################################
Attendees
1. Patrick Robb
2. Ali Alnubani
3. Juraj Linkeš
4. Lijuan Tu
5. Adam Hassick
6. Aaron Conole
7. Jeremy Spewock

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

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

=====================================================================
General Announcements
* DPDK Userspace: Sept 12-13 in Dublin Ireland - Gibson Hotel
* There is a discussion ongoing on the ci mailing list regarding setting up
an email based re-testing request framework. Maintainers and submittors
would be able to send an email in an agreed upon format to trigger a retest
of their patch series.
   * Format could be a key phrase + a list of comma separated list of
context to retest, so like “^Recheck-request: ([a-zA-Z-],? ?)” as proposed
by aaron
   * How do we keep track of recheck requests we’ve already handled?
Message IDs? Or can we just track the patch series and cap the amount of
retests allowed?
   * Best approach is to use patchwork instead of monitoring the mailing
list
   * Need to avoid overloading the patchwork server with requests
      * Upstream patchwork has events API support for requesting comments.
This may solve this problem. Ali is going to talk to Thomas about this
possibility.
   * Agreement needed regarding how long we wait between checking for
retests, how we indicate we’ve done this, other common protocol regarding
our use of patchwork.
      * There is basically a consensus for the ^Recheck-request:
([a-zA-Z-],? ?) format for retest requests

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

---------------------------------------------------------------------
UNH-IOL Community Lab
* The lab has moved from testing Fedora35 and 36, to Fedora37 and 38.
   * Ccache is not working on our fedora38 clang container, significantly
slowing down reporting lag this week. We are currently investigating this
issue.
* We need to re-enable compile test reporting for our windows environment,
which has been posting to our dashboard but not reporting to patchwork.
   * We had some failures yesterday since a patch breaking windows build
was merged into CI since we failed to report the failure to patchwork.
   * Will initiate reruns after this meeting
* We have observed a couple incorrect apply patchset failures in the past
month. After investigating it, it appears that under some circumstances we
were overwriting the output of the pw_maintainers_cli.py (guess git tree)
script and applying to main incorrectly, causing failures.
* Adam has submitted a v6 of the DPDK CI Container build system, having run
it through a spellchecker and linter.
   * To be upstreamed to the dpdk-ci repo:
https://git.dpdk.org/tools/dpdk-ci/
   * Makefiles build dockerfiles based on templates according to a set of
env variables set by the user
   * Uses oci manifests to utilize arm and x86 images in CI
   * Commits across patches which affect the same files have been squashed
together
* Going to take one more look at isolating cores for the Intel-40G x86 test
bed at UNH. If this does not reduce the nic_single_core_perf test variance
below that normal 0-5% we are seeing, we will change the agreed upon
performance variance threshold for a failure to 6% and bring this test bed
back online

---------------------------------------------------------------------
Intel Lab
* Storage is full on a system at Intel Lab which has interrupted CI. This
has been resolved and more storage has been allocated for this system.
   * Retests have been put in
   * Back to normal

---------------------------------------------------------------------
Loongarch Lab
* none

---------------------------------------------------------------------
Github Actions
* Working on upgrades which will facilitate deployment of features like
retest framework
   * New teammember brought in who is working on CI processes with Michael
Santana

=====================================================================
DTS Improvements & Test Development
* Jeremy submitted RFC for DTS smoke tests and utilizing paramiko for ssh +
interactive DPDK apps.
* Juraj is going to be doing traffic gen abstraction work in the immediate
future, and he will review the smoke tests patch when time becomes available
* Juraj is going to be sharing 23.07 roadmap patches with Lijuan so she can
review and provide comments

=====================================================================
Any other business
* Next meeting is June 22

-- 

Patrick Robb

Technical Service Manager

UNH InterOperability Laboratory

21 Madbury Rd, Suite 100, Durham, NH 03824

www.iol.unh.edu

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

                 reply	other threads:[~2023-06-08 14:13 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJvnSUC1NpePoHvB+X9HfOVOtSwbGxgh927g-xFzUbdJr1qrSQ@mail.gmail.com \
    --to=probb@iol.unh.edu \
    --cc=ci@dpdk.org \
    --cc=dts@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).