bodhi SOP: adjust for current state

We can remove a lot of this here thats duplicated in the releng release
notes. We can also remove a section about a bug that was fixed many
years ago upstream and drop atomic composes info.

Signed-off-by: Kevin Fenzi <kevin@scrye.com>
This commit is contained in:
Kevin Fenzi 2023-12-22 09:41:58 -08:00 committed by zlopez
parent 1a819df94f
commit 09aef2a1e7

View file

@ -12,21 +12,12 @@ Bodhi project page: https://github.com/fedora-infra/bodhi
== Contents
* <<_contact_information>>
* <<_adding_a_new_pending_release>>
* <<_pre_beta_bodhi_config>>
* <<_post_beta_bodhi_config>>
* <<_0_day_release_actions>>
* <<_configuring_all_bodhi_nodes>>
* <<_pushing_updates>>
* <<_monitoring_the_bodhi_composer_output>>
* <<_resuming_a_failed_push>>
* <<_performing_a_bodhi_upgrade>>
* <<_syncing_the_production_database_to_staging>>
* <<_release_eol>>
* <<_adding_notices_to_the_front_page_or_new_update_form>>
* <<_using_the_bodhi_shell_to_modify_updates_by_hand>>
* <<_using_the_bodhi_shell_to_fix_uniqueness_problems_with_e_mail_addresses>>
* <<_troubleshooting_and_resolution>>
== Contact Information
@ -34,107 +25,18 @@ Owner::
Fedora Infrastructure Team
Contact::
#fedora-admin
Persons::
bowlofeggs
Location::
iad2
Servers::
* bodhi-backend01.iad2.fedoraproject.org (composer)
* os.fedoraproject.org (web front end and backend task workers for
* bodhi.fedoraproject.org (web front end and backend task workers for
non-compose tasks)
* bodhi-backend01.stg.iad2.fedoraproject.org (staging composer)
* os.stg.fedoraproject.org (staging web front end and backend task
* bodhi.fedoraproject.org (staging web front end and backend task
workers for non-compose tasks)
Purpose::
Push package updates, and handle new submissions.
== Adding a new pending release
Adding and modifying releases is done using the
_bodhi-manage-releases_ tool.
You can add a new pending release by running this command:
....
bodhi-manage-releases create --name F23 --long-name "Fedora 23" --id-prefix FEDORA --version 23 --branch rawhide --dist-tag f23 --stable-tag f23-updates --testing-tag f23-updates-testing --candidate-tag f23-updates-candidate --pending-stable-tag f23-updates-pending --pending-testing-tag f23-updates-testing-pending --override-tag f23-override --package-manager dnf --testing-repository updates-testing --state pending --not-composed-by-bodhi --create-automatic-updates
....
== Pre-Beta Bodhi config
Disable automatic updates creation and enable composes by Bodhi:
....
bodhi-manage-releases edit --name F23 --composed-by-bodhi --no-create-automatic-updates --branch f23
....
Enable pre_beta policy in bodhi config in ansible.::::
ansible/roles/bodhi2/base/templates/production.ini.j2
Uncomment or add the following lines:
....
#f29.status = pre_beta
#f29.pre_beta.mandatory_days_in_testing = 3
#f29.pre_beta.critpath.min_karma = 1
#f29.pre_beta.critpath.stable_after_days_without_negative_karma = 14
....
== Post-Beta Bodhi config
Enable post_beta policy in bodhi config in ansible.::::
ansible/roles/bodhi2/base/templates/production.ini.j2
Comment or remove the following lines corresponding to pre_beta policy:
....
#f29.status = pre_beta
#f29.pre_beta.mandatory_days_in_testing = 3
#f29.pre_beta.critpath.min_karma = 1
#f29.pre_beta.critpath.stable_after_days_without_negative_karma = 14
....
Uncomment or add the following lines for post_beta policy
....
#f29.status = post_beta
#f29.post_beta.mandatory_days_in_testing = 7
#f29.post_beta.critpath.min_karma = 2
#f29.post_beta.critpath.stable_after_days_without_negative_karma = 14
....
== 0-day Release Actions
* update atomic config
* run the ansible playbook
Going from pending to a proper release in bodhi requires a few steps:
Change state from pending to current:
....
bodhi-manage-releases edit --name F23 --state current
....
You may also need to disable any pre-beta or post-beta policy defined in
the bodhi config in ansible.:
....
ansible/roles/bodhi2/base/templates/production.ini.j2
....
Uncomment or remove the lines related to pre and post beta polcy
....
#f29.status = post_beta
#f29.post_beta.mandatory_days_in_testing = 7
#f29.post_beta.critpath.min_karma = 2
#f29.post_beta.critpath.stable_after_days_without_negative_karma = 14
#f29.status = pre_beta
#f29.pre_beta.mandatory_days_in_testing = 3
#f29.pre_beta.critpath.min_karma = 1
#f29.pre_beta.critpath.stable_after_days_without_negative_karma = 14
....
== Configuring all bodhi nodes
Run this command from the _ansible_ checkout to configure
@ -178,7 +80,7 @@ systemd journal on `bodhi-backend01`:
# From the comfort of your own laptop.
$ bodhi composes list
# From bodhi-backend01
$ journalctl -f -u fedmsg-hub
$ journalctl -f -u bodhi-celery
....
== Resuming a failed push
@ -190,13 +92,6 @@ If a push fails for some reason, you can easily resume it on
$ sudo -u apache bodhi-push --resume
....
== Release EOL
....
bodhi-manage-releases edit --name F21 --state archived
....
== Adding notices to the front page or new update form
You can easily add notification messages to the front page of bodhi
@ -250,83 +145,3 @@ original.
>>> delete_update(up2)
>>> t.commit()
....
== Using the Bodhi shell to fix uniqueness problems with e-mail addresses
Bodhi currently enforces uniqueness on user e-mail addresses. There is
https://github.com/fedora-infra/bodhi/issues/2387[an issue] filed to
drop this upstream, but for the time being the constraint is enforced.
This can be a problem for users who have more than one FAS account if
they make one account use an e-mail address that was previously used by
another account, if that other account has not logged into Bodhi since
it was changed to use a different address. One way the user can fix this
themselves is to log in to Bodhi with the old account so that Bodhi
learns about its new address. However, an admin can also fix this by
hand by using the Bodhi shell.
For example, suppose a user has created `user_1` and `user_2`. Suppose
that `user_1` used to use `email_a@example.com` but has been changed to
use `email_b@example.com` in FAS, and `user_2` is now configured to use
`email_a@example.com` in FAS. If `user_2` attempts to log in to Bodhi,
it will cause a uniqueness violation since Bodhi does not know that
`user_1` has changed to `email_b@example.com`. The user can simply log
in as `user_1` to fix this, which will cause Bodhi to update its e-mail
address to `email_b@example.com`. Or an admin can fix it with a shell on
one of the Bodhi backend servers like this:
....
[bowlofeggs@bodhi-backend02 ~][PROD]$ sudo -u apache pshell /etc/bodhi/production.ini
2018-05-29 20:21:36,366 INFO [bodhi][MainThread] Using python-bugzilla
2018-05-29 20:21:36,367 DEBUG [bodhi][MainThread] Using Koji Buildsystem
2018-05-29 20:21:42,559 INFO [bodhi.server][MainThread] Bodhi ready and at your service!
Python 2.7.14 (default, Mar 14 2018, 13:36:31)
[GCC 7.3.1 20180303 (Red Hat 7.3.1-5)] on linux2
Type "help" for more information.
Environment:
app The WSGI application.
registry Active Pyramid registry.
request Active request object.
root Root of the default resource tree.
root_factory Default root factory used to create `root`.
Custom Variables:
m bodhi.server.models
>>> u = m.User.query.filter_by(name=u'user_1').one()
>>> u.email = u'email_b@example.com'
>>> m.Session().commit()
....
== Troubleshooting and Resolution
=== Atomic OSTree compose failure
If the Atomic OSTree compose fails with some sort of
_Device or Resource busy_ error, then run _mount_ to see if there
are any stray _tmpfs_ mounts still active:
....
tmpfs on /var/lib/mock/fedora-22-updates-testing-x86_64/root/var/tmp/rpm-ostree.bylgUq type tmpfs (rw,relatime,seclabel,mode=755)
....
You can then
_umount /var/lib/mock/fedora-22-updates-testing-x86_64/root/var/tmp/rpm-ostree.bylgUq_
and resume the push again.
=== nfs repodata cache IOError
Sometimes you may hit an IOError during the updateinfo.xml generation
process from createrepo_c:
....
IOError: Cannot open /mnt/koji/mash/updates/epel7-160228.1356/../epel7.repocache/repodata/repomd.xml: File /mnt/koji/mash/updates/epel7-160228.1356/../epel7.repocache/repodata/repomd.xml doesn't exists or not a regular file
....
This issue will be resolved with NFSv4, but in the mean time it can be
worked around by removing the _.repocache_ directory and
resuming the push:
....
rm -fr /mnt/koji/mash/updates/epel7.repocache
....