[SPDK] Add Jenkins job for periodic (nightly?) test run against upstream DPDK stable?

[Lance Hartmann ORACLE <lance.hartmann at oracle.com>]

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


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 discussion.

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 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 patches.   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 new SPDK packages because they will be built against a pristine DPDK stable release which very likely is not identical with what we have been testing 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 would 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 confidence of having validated running with the exact version of the 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 quickly deduce it comes at the cost of additional maintenance efforts which can become very unpalatable, esp. when/if some of our patches are never accepted/merged into the official upstream DPDK tree.


--
Lance Hartmann