From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============1704833114467837934==" MIME-Version: 1.0 From: Lance Hartmann ORACLE Subject: Re: [SPDK] Add Jenkins job for periodic (nightly?) test run against upstream DPDK stable? Date: Fri, 15 Feb 2019 12:25:33 -0600 Message-ID: <065C38D4-5D57-4E13-9FF2-DFEB62DC21DD@oracle.com> In-Reply-To: DB3FAAB0ED5FD1449B435E772D1A62BA8A2BFFEE@IRSMSX102.ger.corp.intel.com List-ID: To: spdk@lists.01.org --===============1704833114467837934== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Responses interlined below: > On Feb 15, 2019, at 8:26 AM, Latecki, Karol w= rote: > = > Hi everyone, > We had a talk about this here and we have following proposal about testin= g vs DPDK. > We'd like to start with 3 nightly job configurations, with e-mail notific= ations enabled: Just nightly? I think Jim had initially expressed an interest in doing a = run per-patch I believe with the hope of identifying and addressing any iss= ues more quickly. I'll be eager to hear his (and others') feedback on thi= s. > * SPDK master vs DPDK master When you write "DPDK master" above -- you mean the SPDK's DPDK submodule? = If so, maybe we might refer to that as "sDPDK". > * SPDK master vs DPDK last stable release Again, clarification: By "DPDK last stable release", you certainly mean th= e *upstream* DPDK's most recently cut stable release (suggested notation, "= uDPDK"). However, a new uDPDK stable release is cut one month after each= SPDK release (based on the current respective release schedules). So wou= ld someone (or some automated task?) poll for a newly cut uDPDK stable and = then change the Jenkins job so it started building against that? = > * SPDK last stable release vs DPDK master By "DPDK master", you mean the current master for the SPDK's DPDK submodule= (sDPDK)? > That way we'd know fast enough about new issues between SPDK and DPDK. = > = > I think that your point Jim still applies for these configurations - we'd= have to configure them not to test things that we know are failing. That a= lso means that we would have to re-evaluate the configs from time to time. -- Lance Hartmann > = > Karol > = > -----Original Message----- > From: Harris, James R = > Sent: Thursday, February 14, 2019 3:32 PM > To: Storage Performance Development Kit ; Stojaczyk,= Dariusz ; Latecki, Karol > Subject: Re: [SPDK] Add Jenkins job for periodic (nightly?) test run agai= nst upstream DPDK stable? > = > We could also just switch some of our existing jobs to build/run against = the latest stable DPDK release. We can be careful about picking jobs that = don't have dependencies on patches from our DPDK submodule. > = > =EF=BB=BFOn 2/14/19, 6:39 AM, "SPDK on behalf of Luse, Paul E" wrote: > = > So we talked a lot about this in last night's community meeting and e= veryone agreed as a first step we need to: > = > * create new Jenkins subjob for per-patch testing that tests against l= ast stable DPDK release > * configure the job to not test things that we know will fail (like cr= ypto due to a patch we pushed upstream that won't land until 19.05). There= may be others like this well (some secondary process tests, etc) so it may= take a little experimentation and investigation to get the job right. > * We'll need to review job settings at each release to enable/disable = features to test based on the contents of both the SPDK and DPDK releases a= t the time. > = > Darek/Karol, can you guys get started on this and keep everyone posted? > = > Thanks! = > Paul > = > PS: Thanks Lance for driving this discussion > = > -----Original Message----- > From: Luse, Paul E = > Sent: Tuesday, February 12, 2019 5:10 AM > To: Storage Performance Development Kit > Subject: RE: [SPDK] Add Jenkins job for periodic (nightly?) test run a= gainst upstream DPDK stable? > = > I agree that would be a great addition! For some reason I thought that= was already being done somewhere by someone, no matter though, setting up = a Jenkins job is the right way to do it now. Karol, can you take a look at = this and let everyone know your thoughts? > = > Thanks > Paul > = > -----Original Message----- > From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Lance Har= tmann ORACLE > Sent: Monday, February 11, 2019 4:44 PM > To: spdk(a)lists.01.org > Subject: [SPDK] Add Jenkins job for periodic (nightly?) test run again= st upstream DPDK stable? > = > = > Group, > = > I recently had a sideband chat with Jim regarding our SPDK testing wit= h the DPDK, and he urged I open this up to the email list for more discussi= on. > = > When a Linux distro produces SPDK package rpms, they satisfy the DPDK = dependency via a specified stable DPDK release from upstream that has been = packaged. However, on the run up to each SPDK quarterly release, we are con= stantly building and testing against the SPDK's fork'd copy of the DPDK (as= a git-submodule) on which we often (virtually always?) have our own patche= s. While this works fine for a development perspective as we work toward = the next SPDK release, it's problematic when the time arrives to produce ne= w SPDK packages because they will be built against a pristine DPDK stable r= elease which very likely is not identical with what we have been testing ag= ainst. When I described this with Jim, he agreed that it would be an exce= llent idea to augment our SPDK Jenkins setup with some tests which would ru= n against the latest "pristine" (i.e. upstream stable) DPDK release. With= that in place, when the time arrives to produce new SPDK packages, we will= have gained the testing c > onfidence of having validated running with the exact version of the D= PDK against which the SPDK packages will have been built (and will run alon= gside at runtime). > = > Having said all that, I did float another idea on how we could, if we = really needed to, produce SPDK package rpms based on the combination of a s= table DPDK upstream release and our own collection of patches to it. The = rpm packaging system natively supports such a build, but as you might quick= ly deduce it comes at the cost of additional maintenance efforts which can = become very unpalatable, esp. when/if some of our patches are never accepte= d/merged into the official upstream DPDK tree. > = > = > -- > Lance Hartmann > = > = > = > _______________________________________________ > SPDK mailing list > SPDK(a)lists.01.org > https://lists.01.org/mailman/listinfo/spdk > _______________________________________________ > SPDK mailing list > SPDK(a)lists.01.org > https://lists.01.org/mailman/listinfo/spdk > = > = > -------------------------------------------------------------------- > = > Intel Technology Poland sp. z o.o. > ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wy= dzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-= 316 | Kapital zakladowy 200.000 PLN. > = > Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresa= ta i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej = wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jaki= ekolwiek > przegladanie lub rozpowszechnianie jest zabronione. > This e-mail and any attachments may contain confidential material for the= sole use of the intended recipient(s). If you are not the intended recipie= nt, please contact the sender and delete all copies; any review or distribu= tion by > others is strictly prohibited. > _______________________________________________ > SPDK mailing list > SPDK(a)lists.01.org > https://lists.01.org/mailman/listinfo/spdk --===============1704833114467837934==--