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.