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

Review bodhi SOP

Browse source 
Signed-off-by: Michal Konečný <mkonecny@redhat.com>
This commit is contained in:
Michal Konečný 2021-08-18 11:44:52 +02:00
parent 6016070199
commit dde315ecf5
2 changed files with 44 additions and 42 deletions
Download patch file Download diff file Expand all files Collapse all files

2
modules/sysadmin_guide/nav.adoc
View file

@ -10,7 +10,7 @@
** xref:aws-access.adoc[Amazon Web Services Access - SOP] ** xref:aws-access.adoc[Amazon Web Services Access - SOP]
** xref:bastion-hosts-info.adoc[Fedora Bastion Hosts - SOP] ** xref:bastion-hosts-info.adoc[Fedora Bastion Hosts - SOP]
** xref:blockerbugs.adoc[Blockerbugs Infrastructure - SOP] ** xref:blockerbugs.adoc[Blockerbugs Infrastructure - SOP]
** xref:bodhi.adoc[bodhi - SOP in review ] ** xref:bodhi.adoc[Bodhi Infrastructure - SOP]
** xref:bugzilla2fedmsg.adoc[bugzilla2fedmsg - SOP in review ] ** xref:bugzilla2fedmsg.adoc[bugzilla2fedmsg - SOP in review ]
** xref:bugzilla.adoc[bugzilla - SOP in review ] ** xref:bugzilla.adoc[bugzilla - SOP in review ]
** xref:collectd.adoc[collectd - SOP in review ] ** xref:collectd.adoc[collectd - SOP in review ]

84
modules/sysadmin_guide/pages/bodhi.adoc
View file

@ -5,26 +5,28 @@ for releases and to manage buildroot overrides. From here, bodhi handles
all of the dirty work, from sending around emails, dealing with Koji, to all of the dirty work, from sending around emails, dealing with Koji, to
composing the repositories. composing the repositories.
Bodhi production instance: https://bodhi.fedoraproject.org Bodhi project Bodhi production instance: https://bodhi.fedoraproject.org
page: https://github.com/fedora-infra/bodhi
Bodhi project page: https://github.com/fedora-infra/bodhi
== Contents == Contents
[arabic] * <<_contact_information>>
. Contact Information * <<_adding_a_new_pending_release>>
. Adding a new pending release * <<_pre_beta_bodhi_config>>
. 0-day Release Actions * <<_post_beta_bodhi_config>>
. Configuring all bodhi nodes * <<_0_day_release_actions>>
. Pushing updates * <<_configuring_all_bodhi_nodes>>
. Monitoring the bodhi composer output * <<_pushing_updates>>
. Resuming a failed push * <<_monitoring_the_bodhi_composer_output>>
. Performing a production bodhi upgrade * <<_resuming_a_failed_push>>
. Syncing the production database to staging * <<_performing_a_bodhi_upgrade>>
. Release EOL * <<_syncing_the_production_database_to_staging>>
. Adding notices to the front page or new update form * <<_release_eol>>
. Using the Bodhi Shell to modify updates by hand * <<_adding_notices_to_the_front_page_or_new_update_form>>
. Using the Bodhi shell to fix uniqueness problems with e-mail addresses * <<_using_the_bodhi_shell_to_modify_updates_by_hand>>
. Troubleshooting and Resolution * <<_using_the_bodhi_shell_to_fix_uniqueness_problems_with_e_mail_addresses>>
* <<_troubleshooting_and_resolution>>
== Contact Information == Contact Information
@ -35,12 +37,12 @@ Contact::
Persons:: Persons::
bowlofeggs bowlofeggs
Location:: Location::
Phoenix iad2
Servers:: Servers::
* bodhi-backend01.phx2.fedoraproject.org (composer) * bodhi-backend01.iad2.fedoraproject.org (composer)
* os.fedoraproject.org (web front end and backend task workers for * os.fedoraproject.org (web front end and backend task workers for
non-compose tasks) non-compose tasks)
* bodhi-backend01.stg.phx2.fedoraproject.org (staging composer) * bodhi-backend01.stg.iad2.fedoraproject.org (staging composer)
* os.stg.fedoraproject.org (staging web front end and backend task * os.stg.fedoraproject.org (staging web front end and backend task
workers for non-compose tasks) workers for non-compose tasks)
Purpose:: Purpose::
@ -49,7 +51,7 @@ Purpose::
== Adding a new pending release == Adding a new pending release
Adding and modifying releases is done using the Adding and modifying releases is done using the
[.title-ref]#bodhi-manage-releases# tool. _bodhi-manage-releases_ tool.
You can add a new pending release by running this command: You can add a new pending release by running this command:
@ -129,7 +131,7 @@ Uncomment or remove the lines related to pre and post beta polcy
== Configuring all bodhi nodes == Configuring all bodhi nodes
Run this command from the [.title-ref]#ansible# checkout to configure Run this command from the _ansible_ checkout to configure
all of bodhi in production: all of bodhi in production:
.... ....
@ -141,7 +143,7 @@ $ sudo rbac-playbook openshift-apps/bodhi.yml
== Pushing updates == Pushing updates
SSH into the [.title-ref]#bodhi-backend01# machine and run: SSH into the `bodhi-backend01` machine and run:
.... ....
$ sudo -u apache bodhi-push $ sudo -u apache bodhi-push
@ -228,9 +230,9 @@ playbook:
sudo rbac-playbook -l staging groups/bodhi-backend.yml sudo rbac-playbook -l staging groups/bodhi-backend.yml
.... ....
In the [.title-ref]#os_masters inventory# In the
<https://pagure.io/fedora-infra/ansible/blob/main/f/inventory/group_vars/os_masters_stg>_, https://pagure.io/fedora-infra/ansible/blob/main/f/inventory/group_vars/os_masters_stg[os_masters inventory],
edit the `bodhi_version` setting it to the version you wish to deploy to edit the `bodhi_version` setting to the version you wish to deploy to
staging. For example, to deploy `bodhi-3.13.0-1.fc29.infra` to staging, staging. For example, to deploy `bodhi-3.13.0-1.fc29.infra` to staging,
I would set that varible like this: I would set that varible like this:
@ -261,9 +263,9 @@ playbook:
sudo rbac-playbook groups/bodhi-backend.yml -l bodhi-backend sudo rbac-playbook groups/bodhi-backend.yml -l bodhi-backend
.... ....
In the [.title-ref]#os_masters inventory# In the
<https://pagure.io/fedora-infra/ansible/blob/main/f/inventory/group_vars/os_masters>_, https://pagure.io/fedora-infra/ansible/blob/main/f/inventory/group_vars/os_masters[os_masters inventory],
edit the `bodhi_version` setting it to the version you wish to deploy to edit the `bodhi_version` setting to the version you wish to deploy to
production. For example, to deploy `bodhi-3.13.0-1.fc29.infra` to production. For example, to deploy `bodhi-3.13.0-1.fc29.infra` to
production, I would set that varible like this: production, I would set that varible like this:
@ -297,10 +299,10 @@ bodhi-manage-releases edit --name F21 --state archived
== Adding notices to the front page or new update form == Adding notices to the front page or new update form
You can easily add notification messages to the front page of bodhi You can easily add notification messages to the front page of bodhi
using the [.title-ref]#frontpage_notice# option in using the _frontpage_notice_ option in
[.title-ref]#ansible/roles/bodhi2/base/templates/production.ini.j2#. If _ansible/roles/bodhi2/base/templates/production.ini.j2_. If
you want to flash a message on the New Update Form, you can use the you want to flash a message on the New Update Form, you can use the
[.title-ref]#newupdate_notice# variable instead. This can be useful for _newupdate_notice_ variable instead. This can be useful for
announcing things like service outages, etc. announcing things like service outages, etc.
== Using the Bodhi Shell to modify updates by hand == Using the Bodhi Shell to modify updates by hand
@ -319,9 +321,9 @@ sudo pshell /etc/bodhi/production.ini
>>> execfile('shelldb.py') >>> execfile('shelldb.py')
.... ....
At this point you have access to a [.title-ref]#db# SQLAlchemy Session At this point you have access to a _db_ SQLAlchemy Session
instance, a [.title-ref]#t# [.title-ref]#transaction# module, and instance, a _t_ _transaction module_, and
[.title-ref]#m# for the [.title-ref]#bodhi.models#. _m_ for the _bodhi.models_.
.... ....
# Fetch an update, and tweak it as necessary. # Fetch an update, and tweak it as necessary.
@ -399,16 +401,16 @@ Custom Variables:
=== Atomic OSTree compose failure === Atomic OSTree compose failure
If the Atomic OSTree compose fails with some sort of [.title-ref]#Device If the Atomic OSTree compose fails with some sort of
or Resource busy# error, then run [.title-ref]#mount# to see if there _Device or Resource busy_ error, then run _mount_ to see if there
are any stray [.title-ref]#tmpfs# mounts still active: 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) 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 [.title-ref]#umount You can then
/var/lib/mock/fedora-22-updates-testing-x86_64/root/var/tmp/rpm-ostree.bylgUq# _umount /var/lib/mock/fedora-22-updates-testing-x86_64/root/var/tmp/rpm-ostree.bylgUq_
and resume the push again. and resume the push again.
=== nfs repodata cache IOError === nfs repodata cache IOError
@ -421,7 +423,7 @@ IOError: Cannot open /mnt/koji/mash/updates/epel7-160228.1356/../epel7.repocache
.... ....
This issue will be resolved with NFSv4, but in the mean time it can be This issue will be resolved with NFSv4, but in the mean time it can be
worked around by removing the [.title-ref]#.repocache# directory and worked around by removing the _.repocache_ directory and
resuming the push: resuming the push:
.... ....