| |
@@ -0,0 +1,207 @@
|
| |
+ [[_description]]
|
| |
+ == Description
|
| |
+
|
| |
+ Each release of an EPEL package set is maintained according to the
|
| |
+ following two factors:
|
| |
+
|
| |
+ [arabic]
|
| |
+ . The Red Hat Enterprise Linux is in its main lifetime.
|
| |
+ . There are sufficient volunteers to take care of the packages in that
|
| |
+ release which is judged either by the EPEL Steering committee or in case
|
| |
+ of no remaining members of that body then by Fedora Engineering Steering
|
| |
+ Committee (FESCo).
|
| |
+
|
| |
+ If either of these parameters are met, then Fedora Release engineering
|
| |
+ will begin putting that EPEL package set into `+end of life+` status.
|
| |
+ This document describes the tasks necessary to move a package set to
|
| |
+ that status.
|
| |
+
|
| |
+ [[_actions]]
|
| |
+ == Actions
|
| |
+
|
| |
+ [[_reminder_announcement]]
|
| |
+ === Reminder announcement
|
| |
+
|
| |
+ Send an email to `+devel@+`, `+devel-announce@+`, `+epel-devel@+`,
|
| |
+ `+epel-announce+` and `+announce@+` lists as remainder about the release
|
| |
+ EOL. Use the link:[EPEL EOL template] from the release engineering repo.
|
| |
+
|
| |
+ [NOTE]
|
| |
+ ====
|
| |
+ Due to the slow nature of Enterprise users, this reminder should
|
| |
+ scheduled to be sent 1 month befoee the end of life of the appropriate
|
| |
+ RHEL release. In some cases this may not be possible so the note should
|
| |
+ be sent at least 1 week before the remaining actions occur.
|
| |
+ ====
|
| |
+
|
| |
+ [[_koji_tasks]]
|
| |
+ === Koji tasks
|
| |
+
|
| |
+ * Disable builds by removing targets. Due to the 10 year length of time
|
| |
+ an EPEL release has, the first step is to find all releases which
|
| |
+ generally will have the pattern `+epel-{old_release}+` as in `+epel-8+`.
|
| |
+ Confirm with another Release engineer that these are the ones to be
|
| |
+ removed.
|
| |
+
|
| |
+ ....
|
| |
+ $ koji remove-target epel-{old_release}
|
| |
+ $ koji remove-target epel-{old_release}-candidate
|
| |
+ $ koji remote-target <side-targets> #any side targets that are still around
|
| |
+ ....
|
| |
+
|
| |
+ * Purge from disk the signed copies of rpms that are signed with the
|
| |
+ EOL’d release key. To acheive this, add the release key to
|
| |
+ *koji_cleanup_signed.py* script in https://pagure.io/releng[releng] repo
|
| |
+ and the script on compose-branched01.iad2.fedoraproject.org
|
| |
+
|
| |
+ ....
|
| |
+ ./scripts/koji_cleanup_signed.py
|
| |
+ ....
|
| |
+
|
| |
+ [[_pdc_tasks]]
|
| |
+ === PDC tasks
|
| |
+
|
| |
+ [NOTE]
|
| |
+ ====
|
| |
+ PDC is to be replaced with some other tool and may have been replaced
|
| |
+ several times over the lifetime of an EPEL release. Update this section
|
| |
+ as needed.
|
| |
+ ====
|
| |
+
|
| |
+ * Set PDC *active* value for the release to *False*
|
| |
+
|
| |
+ ....
|
| |
+ curl -u: -H 'Authorization: Token <token>' -H 'Accept: application/json' -H 'Content-Type:application/json' -X PATCH -d '{"active":"false"}' https://pdc.fedoraproject.org/rest_api/v1/releases/epel-{old_release}/
|
| |
+ ....
|
| |
+
|
| |
+ * Set the EOL dates in PDC for all the components to the release EOL
|
| |
+ date if they are not already set. Run the following script from
|
| |
+ https://pagure.io/releng[releng] repo
|
| |
+
|
| |
+ ....
|
| |
+ python scripts/pdc/adjust-eol-all.py <token> f{old_release} 2020-11-24
|
| |
+ ....
|
| |
+
|
| |
+ [[_bodhi_tasks]]
|
| |
+ === Bodhi tasks
|
| |
+
|
| |
+ * Find the appropriate names for that particular EPEL package set. For
|
| |
+ this document, we will assume that it was set up was
|
| |
+ `+EPEL-{old_release}+` but it may have been different.
|
| |
+ * Run the following bodhi commands to set the releases state to
|
| |
+ *archived*
|
| |
+
|
| |
+ ....
|
| |
+ $ bodhi releases edit --name "EPEL-{old_release}" --state archived
|
| |
+ $ bodhi releases edit --name "EPEL-{old_release}M" --state archived
|
| |
+ ....
|
| |
+
|
| |
+ [[_fedora_infra_ansible_changes]]
|
| |
+ === Fedora Infra Ansible Changes
|
| |
+
|
| |
+ * We need to make changes to bodhi, koji, mbs, releng, autosign roles in
|
| |
+ ansible repo.
|
| |
+ * Run the associated playbooks on _batcave_
|
| |
+
|
| |
+ ....
|
| |
+ $ sudo ansible-playbook /srv/web/infra/ansible/playbooks/groups/bodhi-backend.yml
|
| |
+ $ sudo ansible-playbook /srv/web/infra/ansible/playbooks/groups/koji-hub.yml
|
| |
+ $ sudo ansible-playbook /srv/web/infra/ansible/playbooks/groups/mbs.yml
|
| |
+ $ sudo ansible-playbook /srv/web/infra/ansible/playbooks/groups/releng-compose.yml
|
| |
+ $ sudo ansible-playbook /srv/web/infra/ansible/playbooks/groups/proxies.yml -t pkgdb2
|
| |
+ $ sudo ansible-playbook /srv/web/infra/ansible/playbooks/manual/autosign.yml
|
| |
+ $ sudo ansible-playbook /srv/web/infra/ansible/playbooks/openshift-apps/bodhi.yml
|
| |
+ ....
|
| |
+
|
| |
+ [NOTE]
|
| |
+ ====
|
| |
+ Another way to run the playbook is using rbac-playbook, in case one
|
| |
+ don’t have sysadmin-main rights or can’t become root. Syntax: sudo
|
| |
+ rbac-playbook mbs.yml
|
| |
+ ====
|
| |
+
|
| |
+ [[_final_announcement]]
|
| |
+ === Final announcement
|
| |
+
|
| |
+ * Send the final announcement to `+devel@+`, `+devel-announce@+`,
|
| |
+ `+test-announce@+`, `+announce@+` lists.
|
| |
+
|
| |
+ Use the link:[EPEL EOL template] from the release engineering repo
|
| |
+
|
| |
+ [[close-out-all-epel-nn-bugzilla-reports]]
|
| |
+ === Close out all EPEL-NN bugzilla reports.
|
| |
+
|
| |
+ This will require working with administrators who have token access to
|
| |
+ https://bugzilla.redhat.com. Scripts can be run which will collect all
|
| |
+ open EPEL-NN tickets, and then auto-close then with an appropriate
|
| |
+ template letting the user know that the Red Hat Enterprise Linux release
|
| |
+ has reached its End of regular Maintenance and this package will not get
|
| |
+ any further updates.
|
| |
+
|
| |
+ [[_move_the_eol_release_to_archive]]
|
| |
+ ==== Move the EOL release to archive
|
| |
+
|
| |
+ [arabic]
|
| |
+ . Log into to bodhi-backend01 and become root
|
| |
+ +
|
| |
+ ____
|
| |
+ $ ssh bodhi-backend01.iad2.fedoraproject.org $ sudo su $ su - ftpsync
|
| |
+ ____
|
| |
+ . Then change into the releases directory.
|
| |
+ +
|
| |
+ ____
|
| |
+ $ cd /pub/epel/ $ export DATE=$(date -I) $ export
|
| |
+ OLD_REL=\{old_release_number} $ export MINOR=\{last minor release number
|
| |
+ of RHEL like 9 or 10}
|
| |
+ ____
|
| |
+ . Check to see that the target directory doesnt already exist.
|
| |
+ +
|
| |
+ ____
|
| |
+ $ ls /pub/archive/epel/ $ mkdir -p
|
| |
+ /pub/archive/epel/latexmath:[{OLD_REL}.]\{DATE} $ pushd
|
| |
+ /pub/archive/epel/ $ ln -s latexmath:[{OLD_REL}.](date -I)
|
| |
+ latexmath:[{OLD_REL}.]\{MINOR} $ popd
|
| |
+ ____
|
| |
+ . Do a recursive rsync to update any changes in the trees since the
|
| |
+ previous copy.
|
| |
+ +
|
| |
+ ____
|
| |
+ $ rsync -avAXSHP
|
| |
+ ./latexmath:[{OLD_REL}/ /pub/archive/fedora/linux/releases/]\{OLD_REL}.$\{DATE}/
|
| |
+ ____
|
| |
+ . We will now do testing in similar ways.
|
| |
+ +
|
| |
+ ____
|
| |
+ $ cd ../updates/ $ mkdir /pub/archive/epel/latexmath:[{OLD_REL}.]\{DATE}
|
| |
+ $ rsync -avAXSHP
|
| |
+ /pub/latexmath:[{OLD_REL}/ /pub/archive/testing/]\{OLD_REL}.$\{DATE} $
|
| |
+ ____
|
| |
+ . Announce to the mirror list this has been done and that in 2 weeks you
|
| |
+ will move the old trees to archives.
|
| |
+ . In two weeks, log into mm-backend01 and
|
| |
+ [arabic]
|
| |
+ .. Determine what the directory name being used for that release is. It
|
| |
+ might be /\{old_release}/Everything like Fedora or something else.
|
| |
+ .. Run the archive script
|
| |
+ +
|
| |
+ ____
|
| |
+ $ sudo -u mirrormanager mm2_move-to-archive –originalCategory="`EPEL`"
|
| |
+ –archiveCategory="`EPEL Archive`" –directoryRe='`/\{old_release}`'
|
| |
+ ____
|
| |
+ . If there are problems, the postgres DB may have issues and so you need
|
| |
+ to get a DBA to update the backend to fix items.
|
| |
+ . Wait an hour or so then you can remove the files from the main tree.
|
| |
+
|
| |
+ ____
|
| |
+ $ ssh bodhi-backend01 $ cd /pub/epel/\{old_release} $ ls # make sure you
|
| |
+ have stuff here $ rm -rvf * $ ln ../6/README . $ cd
|
| |
+ /pub/epel/testing/\{old_release} $ ls # make sure you have stuff here $
|
| |
+ rm -rf * $ ln ../6/README .
|
| |
+ ____
|
| |
+
|
| |
+ [[_consider_before_running]]
|
| |
+ == Consider Before Running
|
| |
+
|
| |
+ * Resource contention in infrastructure, such as outages
|
| |
+ * Extenuating circumstances for specific planned updates, if any
|
| |
+ * Send the reminder announcement, if it isn’t sent already
|
| |
Now that RHEL 7 is EOL, I think it's safe to just say every 3 years here. RHEL 8 and up are on 3 year major, 6 month minor schedule.