Data model

The sqern suite deals with several types of objects, mostly corresponding to the ones described in the "Concepts" section.

Semi-constant objects

Distro

A Linux distribution that StorPool can be installed on.

Fields:

• name (string): the name of the Linux distribution as used by the spdock suite of build container tools
• variant (string): the build variant of the Linux distribution as used in the StorPool build system and the sp-variant tool
• supported (boolean): does StorPool officially support this Linux distribution or not (too old, too recent, non-LTS, etc.)

Database tables:

• distro

Customer cluster type

The type (support state) of a StorPool cluster, whether deployed in our testing environment or in a customer's production site.

Fields:

• id (integer): the numeric identifier of the cluster type, as seen in the monitoring configuration and possibly used directly in other object
• name (string): a human-readable short name of the cluster type

The list of cluster types that sqern will start out with (the ones currently defined in the monitoring system's configuration) are as follows:

• production (1)
• poc (2)
• custdev (3)
• lab (4)
• out of support (5)
• our test (6)

Database tables:

• cust_cluster_type

Rarely modified objects

KVer

A Linux kernel version for a specific Linux distribution. These objects carry no state at all by themselves; they exist for the purposes of referential integrity (foreign key constraints).

Fields:

• distro (string): the name of the Linux distribution that this kernel version was found in
• version (string): the Linux kernel version itself, usually with some distribution-specific version components (e.g. .el8 or -7-amd64)

Referential integrity:

• distro must correspond to a valid Linux distribution

Database tables:

• kver
• kver_not_ignored

KVerIgnore

A pattern specifying that certain Linux kernel versions for a specific Linux distribution should be ignored - no StorPool build and test runs should be done for them, and the lack of support should not be reflected in any reports.

Fields:

• distro (string): the name of the Linux distribution that kernel versions matching this pattern should be ignored for
• pattern (string): the pattern to match ignored kernel versions; most probably an SQL LIKE expression but maybe a regular expression instead
• comment (string): a human-readable comment describing why these kernel versions should be ignored

Referential integrity:

• distro must correspond to a valid Linux distribution

Database tables:

• kver_ignore

KVerSeen

A Linux kernel version that has been seen in the upstream package repositories of a specific Linux distribution.

Fields:

• distro (string): the name of the Linux distribution
• version (string): the Linux kernel version
• tstamp (timestamp): the moment this kernel version was first seen in the upstream package repositories

Referential integrity:

• (distro, version) must correspond to a valid kernel version

Database tables:

• kver_seen

KVerFetched

A Linux kernel version that our build infrastructure can attempt to build a StorPool package for, i.e. the OS packages containing the kernel header files have been successfully fetched from the upstream repositories of the Linux distribution.

Fields:

• distro (string): the name of the Linux distribution
• version (string): the Linux kernel version
• tstamp (timestamp): the moment the OS packages for this kernel version were fetched from the upstream package repositories

Referential integrity:

• (distro, version) must correspond to a valid kernel version

Database tables:

• kver_fetched

CustCluster

The description of a single deployed StorPool cluster, whether in our internal testing environment or at a customer site.

Fields:

• name (string): the identifier of the StorPool cluster (the SP_CLUSTER_NAME setting in the StorPool configuration)
• cltype (integer): the numeric cluster type

Referential integrity:

• cltype must correspond to a valid cluster type

Database tables:

• cust_cluster

Often-modified objects

CustHostKVer

A single kernel version installed on a host in a StorPool cluster.

Fields:

• cluster_name (string): the name of the StorPool cluster
• host_name (string): the name of the host where the kernel is installed
• distro (string): the Linux distribution on the host
• version (string): the kernel version installed

Referential integrity:

• cluster_name must correspond to a valid StorPool cluster
• (distro, version) must correspond to a valid kernel version

Database tables:

• cust_host_kver

SPBuild

An attempt to build StorPool from a specific source tree.

Fields:

• id (integer): the unique internal identifier of the build, assigned by the database management system
• tstamp (timestamp): the moment the build was started
• result (string, nullable): the build result once it is available, e.g. "SUCCESS", "FAILURE", "ABORTED", etc.
• success (boolean, nullable): a flag indicating whether the build was successful once the result field is set to a non-null value
• jenkins_job (string, nullable): the identifier of the Jenkins job that triggered this build,
• storpool_revision (string): the "21.0.243.620bc3729" version string of the StorPool source tree
• change_id (string): the "Iece2b1a3a04c961d364d1b20c90ae09a34c4e056" identifier string of the StorPool commit message
• official (boolean): is this a build of the StorPool release branch that is suitable for deployment, or merely a development or testing build
• release_target (string): the StorPool testing infrastructure suite that this build is initially meant for e.g. "sp-lab"
• dockernel_profile (string): the name of the StorPool build profile that this build targets, e.g. "exp" or "testing"; possibly only the base name since most builds will probably use ephemeral profiles

Database tables:

• sp_build

SPBuildKVer

A single kernel version that a particular StorPool build attempts to build the StorPool kernel modules for.

Fields:

• build_id (integer): the identifier of the StorPool build
• distro (string): the Linux distribution to build for
• version (string): the kernel version to build for

Referential integrity:

• build_id must correspond to a valid StorPool build
• (distro, version) must correspond to a valid kernel version

Database tables:

• sp_build_kver

SPTest

An attempt to run the StorPool testing suite on the packages produced by a StorPool build.

Fields:

• id (integer): the unique internal identifier of the test run, assigned by the database management system
• tstamp (timestamp): the moment the test run was started
• build_id (integer): the identifier of the StorPool build
• test_flavor (string): the type of the test run as defined by the StorPool autotest infrastructure, e.g. "virtual", "at-hw", etc.
• test_cluster (string): the name of the internal StorPool test cluster used to run the test

Referential integrity:

• build_id must correspond to a valid StorPool build

Database tables:

• sp_test

SPTestKVer

A single kernel version that a particular StorPool test run attempts to validate the StorPool kernel modules for.

Fields:

• test_id (integer): the identifier of the StorPool test run
• distro (string): the Linux distribution to test for
• version (string): the kernel version to test for

Referential integrity:

• test_id must correspond to a valid StorPool test run
• (distro, version) must correspond to a valid kernel version

Database tables:

• sp_test_kver

SPTestResult

The result of a test run once it has completed.

Fields:

• test_id (integer): the identifier of the StorPool test run
• tstamp (timestamp): the moment the test run completed
• result (string): the test run result, e.g. "SUCCESS", "FAILURE", "ABORTED", etc.
• success (boolean): a flag indicating whether the test run was successful

Referential integrity:

• test_id must correspond to a valid StorPool test run

Database tables:

• sp_test_result

Database maintenance objects

Event

An automatically-maintained log-like table of changes made to some types of records, e.g. Distro, KVer, SPBuild, etc.

Fields:

• table_name (string): the type of record the change was made to
• pkey (string): a string identifying the record, a "primary key"; either one of its fields, or a synthetic name built out of several of its fields
• action (string): either "insert" or "update"
• generation (integer): the database generation in which this event occurred
• fields (string): the new value of the tracked fields for this type of record, e.g. the archived state for a Distro record, the change ID, result, etc. of a StorPool build record, etc.
• tstamp (string): the ISO 8601 representation of the time when this event occurred

Referential integrity:

• generation must correspond to a valid generation

Database tables:

• event

Generation

A single set of related changes made to the sqern database.

Fields:

• id (integer): a monotonically increasing identifier
• comment (string): the human-readable rationale for making this set of changes
• username (string): the identifier of the sqern client that makes the changes (e.g. the database role name used to authenticate)
• ipaddr (string): the source address of the sqern client connection, possibly in an [address]:port format (e.g. [192.0.2.42]:616) or (local) for connections via a Unix-domain socket
• tstamp (string): the ISO 8601 representation of the time when this set of changes was made

Database tables:

• generation

Collections

Some actions will operate on more than one object. Some implementations of APIs or tools using this data model may define special names for lists or sets of objects, e.g. KVerList for a list of KVer objects, DistroList for a list of Distro objects, etc.