End Of Life

Description

Each release of Fedora is maintained as laid out in the maintenance schedule. At the conclusion of the maintenance period, a Fedora release enters end of life status. This procedure describes the tasks necessary to move a release to that status. To get the correct EOL date visit release schedule for the last release.

Actions

Reminder announcement

Send an email to devel@, devel-announce@, test-announce@, announce@ lists as remainder about the release EOL. Use template from release engineering repo

Please ensure that the reminder email is scheduled to be sent one week before the end of life.

`fedora-appstream-metadata` package update

Update the fedora-appstream-metadata package with the new EOL date. Follow the instructions from the repo README.

Build the package, create an update and make sure it lands in the stable repo before proceeding.

Koji tasks

Disable builds by removing targets

$ koji remove-target f39
$ koji remove-target f39-candidate
$ koji remove-target f39-container-candidate
$ koji remove-target f39-flatpak-candidate
$ koji remove-target f39-infra
$ koji remove-target f39-coreos-continuous
$ koji remove-target f39-rebuild
$ 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 releng repo and the script on compose-branched01.iad2.fedoraproject.org

./scripts/koji_cleanup_signed.py

PDC tasks

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/fedora-39/

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 releng repo

python scripts/pdc/adjust-eol-all.py <token> f39 2020-11-24

Bodhi tasks

Run the following bodhi commands to set the releases state to archived

$ bodhi releases edit --name "F39" --state archived
$ bodhi releases edit --name "F39M" --state archived
$ bodhi releases edit --name "F39C" --state archived
$ bodhi releases edit --name "F39F" --state archived

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

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

MBS Platform Retirement

To retire the platform in mbs, run the following command on mbs-backend01.iad2.fedoraproject.org

$ sudo mbs-manager retire platform:f39

Final announcement

Send the final announcement to devel@, devel-announce@, test-announce@, announce@ lists.

Use template from release engineering repo

Update FedoraPreviousPrevious.yaml in ansible repository

Set the variable to False

Move the EOL release to archive

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/fedora/linux/releases
Check to see that the target directory doesnt already exist.
$ ls /pub/archive/fedora/linux/releases/
Do a recursive rsync to update any changes in the trees since the previous copy.
$ rsync -avAXSHP ./39/ /pub/archive/fedora/linux/releases/39/

We will now do the updates and updates/testing in similar ways.

$ cd ../updates/
$ rsync -avAXSHP 39/ /pub/archive/fedora/linux/updates/39/
$ cd testing
$ rsync -avAXSHP 39/ /pub/archive/fedora/linux/updates/testing/39/

Do the same with fedora-secondary.

$ cd /pub/fedora-secondary/releases/
$ rsync -avAXSHP ./39/ /pub/archive/fedora-secondary/releases/39/
$ cd ../updates/
$ rsync -avAXSHP 39/ /pub/archive/fedora-secondary/updates/39/
$ cd testing
$ rsync -avAXSHP 39/ /pub/archive/fedora-secondary/updates/testing/39/

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, run the following playbook from batcave:

$ rbac-playbook -v /srv/web/infra/ansible/playbooks/manual/mirrormanager/move-to-archive.yml --extra-vars="product='Fedora' version='39'"

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.

We need to do a cleanup here for both fedora and fedora-secondary for releases, updates, and updates/testing for the 39 release.

$ ssh bodhi-backend01
$ cd /pub/fedora/linux/releases/39
$ ls # make sure you have stuff here
$ rm -rf *
$ ln ../20/README .
$ cd /pub/fedora/linux/updates/39
$ ls # make sure you have stuff here
$ rm -rf *
$ ln ../20/README .
$ cd /pub/fedora/linux/updates/testing/39
$ ls # make sure you have stuff here
$ rm -rf *
$ ln ../20/README .

#for fedora-secondary
$ cd /pub/fedora-secondary/releases/39
$ ls # make sure you have stuff here
$ rm -rf *
$ ln ../20/README .
$ cd /pub/fedora-secondary/updates/39
$ ls # make sure you have stuff here
$ rm -rf *
$ ln ../20/README .
$ cd /pub/fedora-secondary/updates/testing/39
$ ls # make sure you have stuff here
$ rm -rf *
$ ln ../20/README .

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

Want to help? Learn how to contribute to Fedora Docs ›