Completely rewrite the releng "Update Critpath" SOP

This kinda isn't even an SOP any more, because no manual action
is needed in the ordinary course of events any more. We could,
I guess, just remove it. But this instead rewrites it to kinda
explain the process in case manual intervention is needed. The
current information is entirely outdated.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

modules/releng_misc_guide/pages/sop_update_critpath.adoc

@@ -10,46 +10,33 @@ This is a collection of packages deemed "critical" to Fedora
 
 === Description
 
-PDC has information about which packages are critpath and which are not.
-A script that reads the yum repodata (critpath group in comps, and the
-package dependencies) is used to generate this. Since package
-dependencies change, this list should be updated periodically.
+Bodhi has information about which packages are critpath and which are not.
+A script that reads the dnf repodata (critpath groups in comps, and the
+package dependencies) is used to generate this. In the normal course of
+events, an OpenShift cron job (called fedora-bodhi-critpathcron) updates
+this information daily, and no manual intervention is needed, but the
+steps to update it manually are documented here in case of need.
 
 === Action
 
-. Release engineering scripts for updating critpath live in the
-https://pagure.io/releng[releng git repository].
-. Check the critpath.py script to see if the list of releases needs to
-be updated:
+. The release engineering script for updating critpath lives in the
+https://pagure.io/releng[releng git repository]. Check this out.
+. Run the script. If run with `all`, it will generate the info for
+all current releases, and name the output files as Bodhi expects.
+Otherwise you can specify the release to generate info for, and the
+output filename. For stable releases, use the release number. For
+Branched and Rawhide, you can use the release number, or "branched" or
+"rawhide". Using `--srpm` is important as Bodhi expects to get the
+names of SRPMs in the critical path, not binary RPMs.
 +
 ....
-for r in ['12', '13', '14', '15', '16', '17']: # 13, 14, ...
-    releasepath[r] = 'releases/%s/Everything/$basearch/os/' % r
-    updatepath[r] = 'updates/%s/$basearch/' % r
-
-# Branched Fedora goes here
-branched = '18'
+./critpath.py --srpm all
+./critpath.py --srpm -j f38.json 38
 ....
-+
-The for loop has the version numbers for releases that have gone past
-final. branched has the release that's been branched from rawhide but
-not yet hit final. (These have different paths in the repository and may
-not have an updates directory, thus they're in separate sections).
-. Run the script with the release to generate info for (for a release
-that's hit final, this is the release number example: "17". For
-branched, it's "branched").
-+
-....
-./critpath.py --srpm -o critpath.txt branched
-....
-. Run the update script to add that to PDC:
-+
-....
-./update-critpath --user toshio f18 critpath.txt
-....
-+
-The username is your fas username. You must be in cvsadmin to be able to
-change this. The branch is the name of the dist-git branch. critpath.txt
-is the file that the output of critpath.py went into. The script needs a
-PDC token to talk to the server, configured in /etc/pdc.d/. See the PDC
-SOP for more info.
+. Place the generated files in the directory where Bodhi will look
+for them. This is specified by the `critpath.jsonpath` config setting,
+the default is `/etc/bodhi/critpath`. With a monolithic Bodhi server,
+server, this is quite easy. In the current containerized OpenShift
+deployment, we keep this data in a persistent volume and mount it
+at `/etc/bodhi/critpath` in the webUI pod, the consumers pod, and the
+celery pod (which runs the cron job that updates it).