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

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

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

On Tue, Oct 8, 2024 at 4:04 PM Bruce Richardson <bruce.richardson@intel.com>
wrote:

>
> > UNH does not use it much
> >    as we opt to meet the meson dependency separately in the dpdk-ci
> >    project's container template engine.
>
> That's a bit of a pity, since we can't update the meson version
> automatically as part of the meson update as we do with CIs using the
> linux-setup script. Is there some other file that can be in the DPDK main
> repo that can contain this details to regular DPDK patches can update the
> CI too as part of a meson update?
>
>
I think the only way to do that would be to submit a patch alongside for
the dpdk ci container template engine:
https://git.dpdk.org/tools/dpdk-ci/tree/containers/README.md. But this
would not work very well as dpdk-ci is a separate repo from dpdk, so you
can't really package the meson update and the ci update in one patchseries.

So, I guess based on your comments it seems like the best solution is to
remove the meson step from the container template engine (Dockerfiles) and
run the linux-setup.sh script right before each testrun, which solves the
problem you raise about updating dpdk and CI side by side, and solves the
main vs LTS issue. And of course it comes with the benefit of making CI
processes more common across labs. I had run through this idea with Adam
yesterday and we agreed that it would work but decided it was our second
favorite option... but I think with the points you are raising it is clear
this is the correct route to take.


> >    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.
>
> I would recommend against using the DPDK version as a guide. However, the
> meson version is included in the project options in the meson.build file of
> the code. Could you use "grep meson_version meson.build" in a script to
> extra the required version info? If it's helpful, we can possibly provide
> some sort of compatibility guarantee of the format of this line.
>

Thanks this seems like another good option (I did not realize we could get
this from meson.build) and something we can fall back on if usage of the
linux-setup.sh is problematic in any way.

So, we have a different strategy but the timeline should be the same as
this is all fairly trivial. Let me know if yall have any concerns.

Cheers.

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