Re: [OS-Team] [dpdklab] Re: [PATCH 0/5] Increase minimum meson version

[Patrick Robb <probb@iol.unh.edu>]

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

On Tue, Oct 8, 2024 at 4:28 AM David Marchand <david.marchand@redhat.com>
wrote:

>
> This series can't be merged until the (UNH and LoongArch) CI are ready
> for such a change.
>
> TL;DR: the meson minimum version is being changed from 0.53.2 to 0.57
> in the current release.
>
> @UNH @Min Zhou
> How long would it take for all CI to be ready for this change?
>
>
Thanks for the heads up. So, as far as I can tell, this will require an
update to the dpdk/.ci/linux-setup.sh script (which I have just submitted)
as I think various labs rely on it including the github robot, loongson,
Intel (Maybe, I don't know). UNH does not use it much as we opt to meet the
meson dependency separately in the dpdk-ci project's container template
engine.

It will also require updates to the container template engine, which I can
get Cody started on tomorrow.


> Important note: if relevant to your CI, testing against LTS branches
> must still be done with the 0.53.2 version, so no change relying on
> post 0.53.2 meson feature gets backported.
>

Okay, full disclosure I don't think this is something we handled the last
time the meson version got bumped in 2022. So, back then we just bumped the
meson version for all environments to .53, then did LTS testing for 19.11,
20.11, 21.11 from environments running meson .53. But, I understand how
this is an issue and something we should avoid this go around.

However, it is not ideal to set the meson version "at runtime" for CI
testing based on the repo under test (mainline and next-* want .57, old LTS
versions want .53). It would be possible to modify our jenkinsfiles
(automation scripts) to check the DPDK version, and run pip commands
resetting the meson version accordingly, at the start of each testing
job... but I have a couple concerns here with regards to
stability/maintenance.

Another option, which Adam is suggesting, is to create a dedicated
environment which is version locked to .53 (it can just be an ubuntu
container image), label it as a meson .53 environment, and add that to the
total list of dpdk build environments which are run when we do testing for
either 22.11, or 23.11. Then, we could run the rest of the testing from the
same container images we use for mainline (that have .57 baked in), and
this would not be a problem because we would have that 1 environment doing
a dpdk build, which is guaranteed to be on .53. Bruce/David let me know if
you can think of any issues with this.

This is also very similar to a Community Lab request from a few months ago
(which we have an open internal Jira ticket for), which is to add a VM
environment which is locked to the minimum supported kernel version for
DPDK. But, that's another story...

Anyways, in terms of the timeline... the Jenkins script updates are
probably the most difficult in that they will require a PR review, dry run
tests etc. but it's still fairly trivial. Cody can probably update the
meson dependencies on the template engine and submit that to the dpdk-ci
project by end of week. So, I would say CI should be ready by next Tuesday,
provided the patches which will be incoming to dev and ci mailing lists can
be merged. Is this timeline okay?

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