Commit Graph

6 Commits

Author SHA1 Message Date
Michal Berger
e8ea27f859 docker: Add docker-compose for building basic SPDK containers
This suite can be used to deploy containers with the following
functionality (more details in README.md):

- storage-target
- proxy-container
- traffic-generator

This will run simple fio test as per fio.conf against nvmf controller
provided by initiator-container. Similar task can be performed directly
from initiator-container as well.

Each container includes SPDK installation with most common tools, e.g.
rpc.py, available under $PATH. This allows for something like:

docker-compose exec storage-target rpc.py nvmf_get_subsystems

Note that SPDK environment heavily depends on a running kernel hence all
the containers need to be privileged. That said, to make sure containers
are not affecting the host too much, some tasks must be done prior running
them. This includes:

- loading proper kernel modules (like nvme-fabrics, etc.)
- allocating hugepages and having at least one hugetlbfs mount
available under /dev/hugepages

base_build is created as docker multi-stage build.

This is done in order to decrease the size of the final image. The
SPDK RPMs are built inside a base image and then copied over to the
main image (+ fio binary) - this leaves all the dependencies inside
the intermediate image instead of the final one.

The resulted difference in size may look similar to the following
(it may differ depending on the docker version etc.):

no multi-stage build: spdk_base == 1.04GB
multi-stage build: spdk_base == 261MB

Signed-off-by: Michal Berger <michalx.berger@intel.com>
Signed-off-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
Change-Id: I825bd0d0bb4071bd9d44b6a0749c033894899ae0
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/9055
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Monica Kenguva <monica.kenguva@intel.com>
Reviewed-by: Xiaodong Liu <xiaodong.liu@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com>
2021-10-22 07:02:52 +00:00
John Levon
f0b05dd384 scripts/pkgdep: respect $ID_LIKE
As per os-release(5), if $ID is not recognised, $ID_LIKE can be used
to identify similar systems in preference order. Modify the script to try both
variables.

Also do the same for the RPM build scripts.

Signed-off-by: John Levon <john.levon@nutanix.com>
Change-Id: I4ed924df01ec678aab232e114d8c9980463c38e0
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/9260
Community-CI: Mellanox Build Bot
Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Karol Latecki <karol.latecki@intel.com>
Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
Reviewed-by: Dong Yi <dongx.yi@intel.com>
2021-09-06 09:56:14 +00:00
Michal Berger
6317642ce6 rpmbuild: Handle bare --with-dpdk argument
This is done in order to detect if user wants to build spdk RPMs
against DPDK RPMs that might have been installed on the system.

This boils down to the following:

 - if --with-dpdk, with no argument, is detected don't build
   separate RPM holding DPDK libs since user in this case is
   most likely interested only in packaging the SPDK so it
   can coexist with separate DPDK packaging workflow
 - define install and build requirements for the SPDK RPMs
   to depend on dpdk-devel RPM

Signed-off-by: Michal Berger <michalx.berger@intel.com>
Change-Id: I4dd587009da282a114524c74d833fd35ebc5b985
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/8349
Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Karol Latecki <karol.latecki@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
2021-07-12 14:05:20 +00:00
Michal Berger
52652c30cb rpmbuild: Fix Requires section
This particular section must be defined in one place hence the
%{requirements_list} cannot be passed down later on. This requires
reordering of the .spec a bit. Most notably, all global macros are
now defined at the very beginning so then Requires section can be
build properly.

Also, use %() to expand the macro which holds the requirements as
bare "Requires: %{foo}" is not valid.

Signed-off-by: Michal Berger <michalx.berger@intel.com>
Change-Id: I69430f73d10204325fc825ecc392506f261ebaf1
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/8347
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Karol Latecki <karol.latecki@intel.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
2021-06-29 18:17:43 +00:00
Michal Berger
93e6e40442 rpmbuild: Allow to define custom builddir
Alternative for the default of $HOME/rpmbuild.

Signed-off-by: Michal Berger <michalx.berger@intel.com>
Change-Id: Id1feb7207926b518deb87045fc17bb3d1d4c374e
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/8159
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
2021-06-08 08:18:36 +00:00
Michal Berger
7a5cc6cad5 rpmbuild: Add script for building .rpm packages out of the SPDK repo
For now this is kept at its very basics. Dependencies are handled
via pgkdep, they are not explicitly defined by the .rpm itself.
Currently, up to four .rpm packages are being built:

spdk
spdk-devel
spdk-libs
spdk-dpdk-lib

Together they include all binaries|libs|header files + some setup
scripts which are commonly used throughout the repo. Installation
paths are hardcoded to:

/usr/local/{bin,lib{,/dpdk},include}:
  - binaries
  - libraries
  - header files
/usr/libexec/spdk:
  - scripts
/etc:
  - configuration files

Signed-off-by: Michal Berger <michalx.berger@intel.com>
Change-Id: Ic5f067c4e7b8da3d697ee469bc9c794d5a0a035b
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/6436
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
2021-04-15 11:24:57 +00:00