From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0D26A45AF3; Wed, 9 Oct 2024 16:28:52 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 067B7427AB; Wed, 9 Oct 2024 16:28:52 +0200 (CEST) Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by mails.dpdk.org (Postfix) with ESMTP id 808FE4279D for ; Wed, 9 Oct 2024 16:28:50 +0200 (CEST) Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-20bb39d97d1so60853315ad.2 for ; Wed, 09 Oct 2024 07:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1728484130; x=1729088930; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4ZANJ6bVXj0q+jYzvb9TQOhqtYswbb0n0rnNI/rnT2g=; b=WbrRPE4SlCm+51V6vy0XCn43AYgr3Kef4XjFyFBw9AU1K+7FBrJRTHKxMuIsveqeB+ sPazAfBl2C7DWHaSEj/UerPrHD8B0TrRiEqvu8NFXvBr+GAg4/PvT0dAoqaTBOrFpjdY gtaoJ/5/R8GeJj+xVlJuYR0HzMxbdnkdHWw6k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728484130; x=1729088930; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4ZANJ6bVXj0q+jYzvb9TQOhqtYswbb0n0rnNI/rnT2g=; b=XvaGO35wl8WUwQQAfM4N0/LRlo7G9ioFl92liuCHB2+48jPjoKUF44tDaROhD9dW1H TO1NfY7DYcUjx4Dy8ggTt558/IbZr17MkrDp+mlsF1xlfBxkmS/T0U1drdSL8cYlLmtp y5ckLjKNdb35b5O9i1cYIau5eYygduhKCGyt7ugQdTc7IJ01vy0ksougUcoXe95VdmJd +bwt5NkRO756CR52MbfkYrtp09ovwQlQ0ZmWMdlxsZHqqQzo2CXm1+xjFCKw0F8/Y9L+ Fy7ZneWI7T3QFCm6bO6fBbih8VEJckwewBv+gzLjKXMX5TcbR29Y+ycU8CKLxRqr/abr ZFJQ== X-Forwarded-Encrypted: i=1; AJvYcCV3b+1g5yTCYzgCOL01VxgtYM02T/1k1BdWJXDvh+Ae8m6sqqUUKbyPKLa6TOvFpjpWdA==@dpdk.org X-Gm-Message-State: AOJu0Ywll/Egkw3oQ6GakVf6S9QcGvDTYqA10C/OH4iFVEJRylYI2gEp 4p8hdgPXvZCkJaSQL50mdJy8bbwF7cfN3nTI1ZhgO/bMfNsF3XnZPjw4YLSAGpfN4BVOGYV3zUe 7Bsb2hnvo7XBIL3xzBMW9JPzPULQDyZdcp9t04g== X-Google-Smtp-Source: AGHT+IF98Y/wU1SQKSXgl/SHc+wxMgJmK2rUKFVF0HqPEZpSLNTQS0w5JhKvF6yWFTY+JbNhgn/Prwf2VLBNedEaBYM= X-Received: by 2002:a17:903:2442:b0:20b:8036:f77f with SMTP id d9443c01a7336-20c7ed1abcemr351085ad.46.1728484129636; Wed, 09 Oct 2024 07:28:49 -0700 (PDT) MIME-Version: 1.0 References: <20240920125737.1197969-1-bruce.richardson@intel.com> In-Reply-To: From: Patrick Robb Date: Wed, 9 Oct 2024 10:27:30 -0400 Message-ID: Subject: Re: [OS-Team] [dpdklab] Re: [PATCH 0/5] Increase minimum meson version To: Bruce Richardson Cc: David Marchand , dpdklab , Min Zhou , dev@dpdk.org, mb@smartsharesystems.com, thomas@monjalon.net, ci@dpdk.org, "Puttaswamy, Rajesh T" , Cody Cheng , Adam Hassick Content-Type: multipart/alternative; boundary="0000000000008c230306240c1266" X-BeenThere: ci@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK CI discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ci-bounces@dpdk.org --0000000000008c230306240c1266 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 8, 2024 at 4:04=E2=80=AFPM Bruce Richardson 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 branch= es > > must still be done with the 0.53.2 version, so no change relying o= n > > 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 jus= t > > 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 C= I > > 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 testin= g > > 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. --0000000000008c230306240c1266 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Oct 8, 2024 at 4:04=E2=80=AFP= M Bruce Richardson <bruce.= richardson@intel.com> wrote:

> UNH does not use it much
>=C2=A0 =C2=A0 as we opt to meet the meson dependency separately in the = dpdk-ci
>=C2=A0 =C2=A0 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:= =C2=A0https://git.dpdk.org/tools/dpdk-ci/tree/containers/README.md. But t= his would not work very well as dpdk-ci is a separate repo from dpdk, so yo= u can't really package the meson update and the ci update in one patchs= eries.=C2=A0

So, I guess based on your comments it= seems like the best solution is to remove the meson step from the containe= r template engine (Dockerfiles) and run the linux-setup.sh script right bef= ore each testrun, which solves the problem you raise about updating dpdk an= d 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 y= ou are raising it is clear this is the correct route to take.=C2=A0
=C2=A0
>=C2=A0 =C2=A0 It will also require updates to the container template en= gine, which I
>=C2=A0 =C2=A0 can get Cody started on tomorrow.
>
>=C2=A0 =C2=A0 =C2=A0 Important note: if relevant to your CI, testing ag= ainst LTS branches
>=C2=A0 =C2=A0 =C2=A0 must still be done with the 0.53.2 version, so no = change relying on
>=C2=A0 =C2=A0 =C2=A0 post 0.53.2 meson feature gets backported.
>
>=C2=A0 =C2=A0 Okay, full disclosure I don't think this is something= we handled the
>=C2=A0 =C2=A0 last time the meson version got bumped in 2022. So, back = then we just
>=C2=A0 =C2=A0 bumped the meson version for all environments to .53, the= n did LTS
>=C2=A0 =C2=A0 testing for 19.11, 20.11, 21.11 from environments running= meson .53.
>=C2=A0 =C2=A0 But, I understand how this is an issue and something we s= hould avoid
>=C2=A0 =C2=A0 this go around.
>=C2=A0 =C2=A0 However, it is not ideal to set the meson version "a= t runtime" for CI
>=C2=A0 =C2=A0 testing based on the repo under test (mainline and next-*= want .57, old
>=C2=A0 =C2=A0 LTS versions want .53). It would be possible to modify ou= r jenkinsfiles
>=C2=A0 =C2=A0 (automation scripts) to check the DPDK version, and run p= ip commands
>=C2=A0 =C2=A0 resetting the meson version accordingly, at the start of = each testing
>=C2=A0 =C2=A0 job... but I have a couple concerns here with regards to<= br> >=C2=A0 =C2=A0 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 scr= ipt to
extra the required version info? If it's helpful, we can possibly provi= de
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.
=C2=A0
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 con= cerns.

Cheers.
--0000000000008c230306240c1266--