From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============3855953182991042898==" MIME-Version: 1.0 From: Harris, James R Subject: Re: [SPDK] Add Jenkins job for periodic (nightly?) test run against upstream DPDK stable? Date: Fri, 15 Feb 2019 21:25:47 +0000 Message-ID: In-Reply-To: 90D68AB6-2FB2-4A99-8AB9-588D8F54B0B0@oracle.com List-ID: To: spdk@lists.01.org --===============3855953182991042898== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable =EF=BB=BFOn 2/15/19, 2:19 PM, "SPDK on behalf of Lance Hartmann ORACLE" wrote: = = So the risk on nightly-testing for #2 is the scenario that a submitted = patch passed against the DPDK submodule, was quickly reviewed and then merg= ed before we would find out later -- overnight -- that the same patch again= st the DPDK last stable did not. I don't know how often the case exists w= here a newly submitted patch runs through the test-pool, gets two maintaine= r's reviews and merged all in a single day. That said, do you fear that b= y always holding off one day before doing a merge, we could inspect the ove= rnight test against DPDK stable first? [Jim] Well...the nightly testing would be done against tip of the SPDK mast= er branch - meaning only against patches that have been merged. So by defi= nition, what you're describing is exactly how we would find problems with D= PDK last stable that aren't there with the DPDK submodule. As a project, w= e'll need to treat these failures with the utmost priority - in most cases = immediately reverting while it can be investigated. = I'd also like to pose my question again with respect to "DPDK last stab= le". Right now as I compose this per http://core.dpdk.org/download/, they= identify "Latest Stable" as 18.05.1 (which I find surprising and wonder if= that's correct). They identify "Latest Major" as 19.02 (released 2019, F= ebruary 1st), and the release prior to that was DPDK 18.11.0 (LTS). So, = given those three (3) versions of the upstream DPDK, which of them aligns w= ith our use of the term "DPDK last stable release"? = [Jim] Good point, we need to be more precise on this. I had been thinking = "latest major" release, since that's what the DPDK submodule is based on. = = -- Lance Hartmann = = = > = > -Jim > = > = > On 2/15/19, 11:25 AM, "Lance Hartmann ORACLE" wrote: > = > = > Responses interlined below: > = > = > = >> On Feb 15, 2019, at 8:26 AM, Latecki, Karol wrote: >> = >> Hi everyone, >> We had a talk about this here and we have following proposal about t= esting vs DPDK. >> We'd like to start with 3 nightly job configurations, with e-mail no= tifications 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 addressin= g any issues more quickly. I'll be eager to hear his (and others') feedba= ck on this. > = > = >> * SPDK master vs DPDK master > = > When you write "DPDK master" above -- you mean the SPDK's DPDK sub= module? 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 certainl= y mean the *upstream* DPDK's most recently cut stable release (suggested no= tation, "uDPDK"). However, a new uDPDK stable release is cut one month a= fter each SPDK release (based on the current respective release schedules).= So would someone (or some automated task?) poll for a newly cut uDPDK st= able 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 DPD= K. = >> = >> 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. T= hat also means that we would have to re-evaluate the configs from time to t= ime. > = > = > -- > Lance Hartmann > = > = > = >> = >> Karol >> = >> -----Original Message----- >> From: Harris, James R = >> Sent: Thursday, February 14, 2019 3:32 PM >> To: Storage Performance Development Kit ; Stoja= czyk, Dariusz ; Latecki, Karol >> Subject: Re: [SPDK] Add Jenkins job for periodic (nightly?) test run= against upstream DPDK stable? >> = >> We could also just switch some of our existing jobs to build/run aga= inst the latest stable DPDK release. We can be careful about picking jobs = that don't have dependencies on patches from our DPDK submodule. >> = >> On 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 a= nd everyone agreed as a first step we need to: >> = >> * create new Jenkins subjob for per-patch testing that tests again= st last stable DPDK release >> * configure the job to not test things that we know will fail (lik= e crypto due to a patch we pushed upstream that won't land until 19.05). T= here 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/disa= ble features to test based on the contents of both the SPDK and DPDK releas= es at the time. >> = >> Darek/Karol, can you guys get started on this and keep everyone po= sted? >> = >> 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 r= un against 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= Hartmann 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 a= gainst upstream DPDK stable? >> = >> = >> Group, >> = >> I recently had a sideband chat with Jim regarding our SPDK testing= with the DPDK, and he urged I open this up to the email list for more disc= ussion. >> = >> When a Linux distro produces SPDK package rpms, they satisfy the D= PDK dependency via a specified stable DPDK release from upstream that has b= een packaged. However, on the run up to each SPDK quarterly release, we are= constantly 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 pa= tches. While this works fine for a development perspective as we work tow= ard the next SPDK release, it's problematic when the time arrives to produc= e new SPDK packages because they will be built against a pristine DPDK stab= le release which very likely is not identical with what we have been testin= g against. When I described this with Jim, he agreed that it would be an = excellent idea to augment our SPDK Jenkins setup with some tests which woul= d run 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 t= he DPDK against which the SPDK packages will have been built (and will run = alongside 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 stable DPDK upstream release and our own collection of patches to it. = The rpm packaging system natively supports such a build, but as you might q= uickly deduce it comes at the cost of additional maintenance efforts which = can become very unpalatable, esp. when/if some of our patches are never acc= epted/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 | V= II Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-0= 7-52-316 | Kapital zakladowy 200.000 PLN. >> = >> Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego a= dresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania= tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie;= jakiekolwiek >> przegladanie lub rozpowszechnianie jest zabronione. >> This e-mail and any attachments may contain confidential material fo= r the sole use of the intended recipient(s). If you are not the intended re= cipient, please contact the sender and delete all copies; any review or dis= tribution by >> others is strictly prohibited. >> _______________________________________________ >> 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 = --===============3855953182991042898==--