WaiverDB is a service for recording waivers, from humans, that correspond with results in ResultsDB.
On its own, it doesn’t do much.
Importantly, the Greenwave service queries resultsdb and waiverdb and makes decisions (for Bodhi and other tools) based on the combination of data from the two sources. A result in resultsdb may matter, unless waived in waiverdb.
Factory2 Team, Fedora QA Team, Infrastructure Team
dcallagh, gnaponie (giulia), lholecek, ralph (threebean)
- Public addresses
Record waivers and respond to queries about them.
See the the upstream API docs for detailed information. The information here will be contextual to the Fedora environment.
There will be two ways of inserting waivers into waiverdb:
First, a cli tool, which performs a HTTP POST from the packager’s machine.
Second, a proxied request from bodhi. In this case, the packager will click a button in the Bodhi UI (next to a failing test result). Bodhi will receive the request from the user and in turn submit a POST to waiverdb on the user’s behalf. Here, the Bodhi Server will authenticate as the bodhi user, but request that the waiver be recorded as having been submitted by the original packager. Bodhi’s account will have to be given special proxy privileges in waiverdb. See https://pagure.io/waiverdb/issue/77
Login to os-master01.iad2.fedoraproject.org as
root (or authenticate remotely with openshift using
oc login https://os.fedoraproject.org, and run:
$ oc project waiverdb $ oc status -v $ oc logs -f dc/waiverdb-web
In general, don’t do this. But if for some reason we really need to, the database for waiverdb lives outside of openshift in our standard environment. Connect to db01:
[root@db01 ~][PROD]# sudo -u postgres psql waiverdb waiverdb=# \d List of relations Schema | Name | Type | Owner --------+---------------+----------+---------- public | waiver | table | waiverdb public | waiver_id_seq | sequence | waiverdb (2 rows) waiverdb=# select * from waiver;
Be careful. You can delete individual waivers with SQL.
You can roll out configuration changes by changing the files in
and running the
To understand how the software is deployed, take a look at these two files:
See that we build a fedora-infra specific image on top of an app image published by upstream. The latest tag is automatically deployed to staging. This should represent the latest commit to the master branch of the upstream git repo that passed its unit and functional tests.
The prod tag is manually controlled. To upgrade prod to match what is in stage, move the prod tag to point to the same image as the latest tag. Our buildconfig is configured to poll that tag, so a new os.fp.o build and deployment should be automatically created.
You can watch the build and deployment with oc commands.
You can poll this URL to see what version is live at the moment: https://waiverdb-web-waiverdb.app.os.fedoraproject.org/api/v1.0/about