Infrastructure/infra-docs-fpo
1
0
Fork 0
Code Issues 100 Pull requests 6 Projects Releases Packages Wiki Activity Actions

Review pdc SOP

Browse source 
Signed-off-by: Michal Konečný <mkonecny@redhat.com>
This commit is contained in:
Michal Konečný 2021-09-09 15:06:23 +02:00
parent f10ecdac2b
commit 6de335abf0
2 changed files with 38 additions and 32 deletions
Download patch file Download diff file Expand all files Collapse all files

2
modules/sysadmin_guide/nav.adoc
View file

@ -86,7 +86,7 @@
** xref:outage.adoc[Outage Infrastructure - SOP]
** xref:packagereview.adoc[Package Review - SOP]
** xref:pagure.adoc[Pagure Infrastructure - SOP]
** xref:pdc.adoc[pdc - SOP in review ]
** xref:pdc.adoc[PDC - SOP]
** xref:pesign-upgrade.adoc[pesign-upgrade - SOP in review ]
** xref:planetsubgroup.adoc[planetsubgroup - SOP in review ]
** xref:publictest-dev-stg-production.adoc[publictest-dev-stg-production - SOP in review ]

68
modules/sysadmin_guide/pages/pdc.adoc
View file

@ -2,8 +2,10 @@
Store metadata about composes we produce and "component groups".
App: https://pdc.fedoraproject.org/ Source for frontend:
https://github.com/product-definition-center/product-definition-center
App: https://pdc.fedoraproject.org/
Source for frontend: https://github.com/product-definition-center/product-definition-center
Source for backend: https://github.com/fedora-infra/pdc-updater
== Contact Information
@ -27,12 +29,12 @@ tooling down the road for future releases.
The webapp is a django app running on pdc-web0\{1,2}. Unlike most of our
other apps, it does not use OpenID for authentication, but it instead
uses SAML2. It uses [.title-ref]#mod_auth_mellon# to achieve this (in
uses SAML2. It uses _mod_auth_mellon_ to achieve this (in
cooperation with ipsilon). The webapp allows new data to be POST'd to it
by admin users.
The backend is a [.title-ref]#fedmsg-hub# process running on
pdc-backend01. It listens for new composes over fedmsg and then POSTs
The backend is a _fedmsg-hub_ process running on
_pdc-backend01_. It listens for new composes over fedmsg and then POSTs
data about those composes to PDC. It also listens for changes to the
fedora atomic host git repo in pagure and updates "component groups" in
PDC to reflect what rpm components constitute fedora atomic host.
@ -40,7 +42,10 @@ PDC to reflect what rpm components constitute fedora atomic host.
For long-winded history and explanation, see the original Change
document: https://fedoraproject.org/wiki/Changes/ProductDefinitionCenter
NOTE: pdc is being replaced by fpdc (Fedora Product Definition Center)
[NOTE]
====
PDC is being replaced by fpdc (Fedora Product Definition Center)
====
== Upgrading the Software
@ -51,32 +56,32 @@ a run of that playbook.
== Logs
Logs for the frontend are in [.title-ref]#/var/log/httpd/error_log# on
Logs for the frontend are in `/var/log/httpd/error_log` on
pdc-web0\{1,2}.
Logs for the backend can be accessed with [.title-ref]#journalctl -u
fedmsg-hub -f# on pdc-backend01.
Logs for the backend can be accessed with
`journalctl -u fedmsg-hub -f` on _pdc-backend01_.
== Restarting Services
The frontend runs under apache. So either [.title-ref]#apachectl
graceful# or [.title-ref]#systemctl restart httpd# should do it.
The frontend runs under apache. So either `apachectl graceful`
or `systemctl restart httpd` should do it.
The backend runs as a fedmsg-hub, so [.title-ref]#systemctl restart
fedmsg-hub# should restart it.
The backend runs as a _fedmsg-hub_, so
`systemctl restart fedmsg-hub` should restart it.
== Scripts
The pdc-updater package (installed on pdc-backend01) provides three
The _pdc-updater_ package (installed on _pdc-backend01_) provides three
scripts:
* pdc-updater-audit
* pdc-updater-retry
* pdc-updater-initialize
* `pdc-updater-audit`
* `pdc-updater-retry`
* `pdc-updater-initialize`
A possible failure scenario is that we will lose a fedmsg message and
the backend will not update the frontend with info about that compose.
To detect this, we provide the [.title-ref]#pdc-updater-audit# command
To detect this, we provide the `pdc-updater-audit` command
(which gets run once daily by cron with emails sent to the releng-cron
list). It compare all of the entries in PDC with all of the entries in
kojipkgs and then raises an alert if there is a discrepancy.
@ -84,9 +89,9 @@ kojipkgs and then raises an alert if there is a discrepancy.
Another possible failure scenario is that the fedmsg message is
published and received correctly, but there is some processing error
while handling it. The event occurred, but the import to the PDC db
failed. The [.title-ref]#pdc-updater-audit# script should detect this
failed. The `pdc-updater-audit` script should detect this
discrepancy, and then an admin will need to manually repair the problem
and retry the event with the [.title-ref]#pdc-updater-retry# command.
and retry the event with the `pdc-updater-retry` command.
If doomsday occurs and the whole thing is totally hosed, you can delete
the db and re-ingest all information available from releng with the
@ -95,14 +100,14 @@ happen on pdc-web01 with the standard django settings.py commands.)
== Manually Updating Information
In general, you shouldn't have to do these things. pdc-updater will
In general, you shouldn't have to do these things. `pdc-updater` will
automatically create new releases and update information, but if you
ever need to manipulate PDC data, you can do it with the pdc-client
tool. A copy is installed on pdc-backend01 and there are some
ever need to manipulate PDC data, you can do it with the _pdc-client_
tool. A copy is installed on _pdc-backend01_ and there are some
credentials there you'll need, so ssh there first.
Make sure that you are root so that you can read
[.title-ref]#/etc/pdc.d/fedora.json#.
`/etc/pdc.d/fedora.json`.
Try listing all of the releases:
@ -117,11 +122,10 @@ $ pdc -s fedora release update fedora-21-updates --deactivate
....
[NOTE]
.Note
====
There are lots more attribute you can manipulate on a release (you can
change the type, and rename them, etc..) See [.title-ref]#pdc --help#
and [.title-ref]#pdc release --help# for more information.
change the type, and rename them, etc..) See `pdc --help`
and `pdc release --help` for more information.
====
Listing all composes:
@ -139,9 +143,11 @@ https://github.com/product-definition-center/product-definition-center/issues/42
Some small group of release engineers need to be superuser to set eol
dates and add/remove components. You can grant them permissions to do
this via some direct database calls. First find out their email address
listed in fas, then login to db01.phx2.fedoraproject.org:
listed in fas, then login to _db01.iad2.fedoraproject.org_:
sudo -u postgresql psql pdc pdc-# update kerb_auth_user set is_superuser
= 'true' where email = 'usersemailfromfas';
....
sudo -u postgresql psql pdc pdc-
# update kerb_auth_user set is_superuser = 'true' where email = 'usersemailfromfas';
....
the user will now have privs with their normal tokens.
The user will now have privs with their normal tokens.