Review waiverdb SOP

Signed-off-by: Michal Konečný <mkonecny@redhat.com>
This commit is contained in:
Michal Konečný 2021-09-10 16:33:24 +02:00
parent 26a452409a
commit 9dd9ba2962
2 changed files with 16 additions and 18 deletions

View file

@ -112,7 +112,7 @@
** xref:virtio.adoc[Virtio Notes - SOP] ** xref:virtio.adoc[Virtio Notes - SOP]
** xref:virt-notes.adoc[Fedora Infrastructure Libvirt Notes - SOP] ** xref:virt-notes.adoc[Fedora Infrastructure Libvirt Notes - SOP]
** xref:voting.adoc[Voting Infrastructure - SOP] ** xref:voting.adoc[Voting Infrastructure - SOP]
** xref:waiverdb.adoc[waiverdb - SOP in review ] ** xref:waiverdb.adoc[WaiverDB - SOP]
** xref:wcidff.adoc[wcidff - SOP in review ] ** xref:wcidff.adoc[wcidff - SOP in review ]
** xref:wiki.adoc[wiki - SOP in review ] ** xref:wiki.adoc[wiki - SOP in review ]
** xref:zodbot.adoc[zodbot - SOP in review ] ** xref:zodbot.adoc[zodbot - SOP in review ]

View file

@ -3,7 +3,7 @@
WaiverDB is a service for recording waivers, from humans, that WaiverDB is a service for recording waivers, from humans, that
correspond with results in ResultsDB. correspond with results in ResultsDB.
On its own, this doesn't do much. On its own, it doesn't do much.
Importantly, the _Greenwave_ service queries resultsdb _and_ waiverdb Importantly, the _Greenwave_ service queries resultsdb _and_ waiverdb
and makes decisions (for _Bodhi_ and other tools) based on the and makes decisions (for _Bodhi_ and other tools) based on the
@ -18,8 +18,6 @@ Contact::
#fedora-qa, #fedora-admin #fedora-qa, #fedora-admin
Persons:: Persons::
dcallagh, gnaponie (giulia), lholecek, ralph (threebean) dcallagh, gnaponie (giulia), lholecek, ralph (threebean)
Location::
Phoenix
Public addresses:: Public addresses::
* https://waiverdb-web-waiverdb.app.os.fedoraproject.org/api/v1.0/about * https://waiverdb-web-waiverdb.app.os.fedoraproject.org/api/v1.0/about
* https://waiverdb-web-waiverdb.app.os.fedoraproject.org/api/v1.0/waivers * https://waiverdb-web-waiverdb.app.os.fedoraproject.org/api/v1.0/waivers
@ -30,7 +28,7 @@ Purpose::
== Description == Description
See the https://pagure.io/docs/waiverdb/[the upstream API docs for See the https://waiverdb.readthedocs.io/en/latest/index.html[the upstream API docs for
detailed information]. The information here will be contextual to the detailed information]. The information here will be contextual to the
Fedora environment. Fedora environment.
@ -50,9 +48,9 @@ https://pagure.io/waiverdb/issue/77
== Observing WaiverDB Behavior == Observing WaiverDB Behavior
Login to [.title-ref]#os-master01.phx2.fedoraproject.org# as Login to _os-master01.iad2.fedoraproject.org_ as
[.title-ref]#root# (or, authenticate remotely with openshift using _root_ (or authenticate remotely with openshift using
[.title-ref]#oc login https://os.fedoraproject.org#), and run: `oc login https://os.fedoraproject.org`, and run:
.... ....
$ oc project waiverdb $ oc project waiverdb
@ -85,28 +83,28 @@ Be careful. You can delete individual waivers with SQL.
== Upgrading == Upgrading
You can roll out configuration changes by changing the files in You can roll out configuration changes by changing the files in
[.title-ref]#roles/openshift-apps/waiverdb/# and running the https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openshift-apps/waiverdb[roles/openshift-apps/waiverdb/]
[.title-ref]#playbooks/openshift-apps/waiverdb.yml# playbook. and running the `playbooks/openshift-apps/waiverdb.yml` playbook.
To understand how the software is deployed, take a look at these two To understand how the software is deployed, take a look at these two
files: files:
* [.title-ref]#roles/openshift-apps/waiverdb/templates/imagestream.yml# * `roles/openshift-apps/waiverdb/templates/imagestream.yml`
* [.title-ref]#roles/openshift-apps/waiverdb/templates/buildconfig.yml# * `roles/openshift-apps/waiverdb/templates/buildconfig.yml`
See that we build a fedora-infra specific image on top of an app image See that we build a fedora-infra specific image on top of an app image
published by upstream. The [.title-ref]#latest# tag is automatically published by upstream. The _latest_ tag is automatically
deployed to staging. This should represent the latest commit to the deployed to staging. This should represent the latest commit to the
[.title-ref]#master# branch of the upstream git repo that passed its _master_ branch of the upstream git repo that passed its
unit and functional tests. unit and functional tests.
The [.title-ref]#prod# tag is manually controlled. To upgrade prod to The _prod_ tag is manually controlled. To upgrade prod to
match what is in stage, move the [.title-ref]#prod# tag to point to the match what is in stage, move the _prod_ tag to point to the
same image as the [.title-ref]#latest# tag. Our buildconfig is same image as the _latest_ tag. Our buildconfig is
configured to poll that tag, so a new os.fp.o build and deployment configured to poll that tag, so a new os.fp.o build and deployment
should be automatically created. should be automatically created.
You can watch the build and deployment with [.title-ref]#oc# commands. You can watch the build and deployment with _oc_ commands.
You can poll this URL to see what version is live at the moment: 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 https://waiverdb-web-waiverdb.app.os.fedoraproject.org/api/v1.0/about