DPDK CI discussions
 help / color / mirror / Atom feed
* [dpdk-ci] [RFC] test lab database schema
@ 2017-11-09 23:53 Patrick MacArthur
  2017-11-10 12:33 ` Shepard Siegel
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Patrick MacArthur @ 2017-11-09 23:53 UTC (permalink / raw)
  To: ci; +Cc: Bob Noseworthy

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

Hi, all,

I have been working on a database schema for storing performance
results. I am attempting to make this generic enough to store whatever
measurements we want.

I have attached an entity-relationship diagram of the schema which
should illustrate the starting point for the schema.

As a side note, I have managed to get DTS to run some of the
functional tests on a pair of nodes locally in a test setup while I
wait for equipment to be ready to ship. I am still working on a setup
to get it to run the performance tests so I can get some output to
parse to begin working on pulling information into the database.

Some notes on the tables:

patch: I propose that for this schema patches will be stored on the
filesystem content-addressable by the sha256 hash of the patch file.

patchset: "branch" refers to corresponding repo (master -> dpdk,
dpdk-next-net -> dpdk/next-net, etc.) and will be NULL until the
patchset is applied. Tarballs stored as files named after patchset id.

patchset_result: Result entry for a patchset. A patchset passes if
there is a result for every measurement which is either PASS or N/A.

environment: This should represent everything about where the test was
run and a new environment needs to be created every time this changes
(e.g., kernel or compiler update). I gathered the list of fields by
looking at the existing performance reports on the DPDK website. This
can be used for verification, to allow the test environment to be
reproducible, and to ensure that all comparisons are within an
identical setup.

measurement: A single measurement which can be applied to any
patchset. We can use values like (name: “BUILD”, higherIsBetter: TRUE,
expectedValue: 1, deltaLimit: 0) to verify non-performance conditions,
such as the build succeeding for the given environment.

The primary keys for these tables are not shown; I will likely be
implementing the database using the data modeling framework for
whatever Web backend we wind up selecting, which will set up primary
keys and table join relationships automatically.

Comments/suggestions? Is there anything that this schema does not cover?

Thanks,
Patrick

-- 
Patrick MacArthur
Research and Development, High Performance Networking and Storage
UNH InterOperability Laboratory

[-- Attachment #2: Test Result ERD.pdf --]
[-- Type: application/pdf, Size: 15176 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2017-11-28 17:26 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-09 23:53 [dpdk-ci] [RFC] test lab database schema Patrick MacArthur
2017-11-10 12:33 ` Shepard Siegel
2017-11-28 14:14 ` Thomas Monjalon
2017-11-28 16:32 ` Gema Gomez
2017-11-28 17:13   ` Thomas Monjalon
2017-11-28 17:26     ` Gema Gomez

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).