Roadmap

This describes some plans for the future of WaiverDB. Items are listed in approximate order of importance.

Using WaiverDB

Currently there is no easy way to actually use WaiverDB as a user submitting waivers. Ultimately we envisage that the consuming tools (for example, Bodhi) will include some user interface elements to create new waivers in the same place where they show the failing test results. However as a stop-gap there is:

  • #82: Provide a command-line interface to submit waivers

There is one additional wrinkle. WaiverDB deployments running in OpenShift cannot use Kerberos authentication, because clients mostly default to dns_canonicalize_hostname=true which is fundamentally incompatible with how OpenShift routes traffic to applications. In that case, something like SSL certification authentication will need to be used instead:

  • #76: Support SSL certificate authentication

But we can’t reasonably expect end users to obtain an SSL certificate for submitting waivers, so we will need the consuming tool (Bodhi or equivalent) to make the request to WaiverDB on behalf of the real human user. In that case WaiverDB will need to trust the calling service to tell it who the real human user was:

  • #77: Allow “proxy user” waiving for a configured list of “super users”

Results may be absent

One situation we anticipate is that a gating point is being held up a slow test system or an outage in the infrastructure. In some cases (for example, shipping urgent security advisories) humans may decide that it is worth the risk to bypass the test requirement even if there is no result yet.

  • #80: Ability to waive the absence of a result
  • #81: Ability to waive all results