diff --git a/modules/sysadmin_guide/nav.adoc b/modules/sysadmin_guide/nav.adoc index 5c290bb..170376d 100644 --- a/modules/sysadmin_guide/nav.adoc +++ b/modules/sysadmin_guide/nav.adoc @@ -10,7 +10,7 @@ ** xref:aws-access.adoc[Amazon Web Services Access - SOP] ** xref:bastion-hosts-info.adoc[Fedora Bastion Hosts - 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:bugzilla.adoc[bugzilla - SOP in review ] ** xref:collectd.adoc[collectd - SOP in review ] diff --git a/modules/sysadmin_guide/pages/bodhi.adoc b/modules/sysadmin_guide/pages/bodhi.adoc index 7e379fe..5a17754 100644 --- a/modules/sysadmin_guide/pages/bodhi.adoc +++ b/modules/sysadmin_guide/pages/bodhi.adoc @@ -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 composing the repositories. -Bodhi production instance: https://bodhi.fedoraproject.org Bodhi project -page: https://github.com/fedora-infra/bodhi +Bodhi production instance: https://bodhi.fedoraproject.org + +Bodhi project page: https://github.com/fedora-infra/bodhi == Contents -[arabic] -. Contact Information -. Adding a new pending release -. 0-day Release Actions -. Configuring all bodhi nodes -. Pushing updates -. Monitoring the bodhi composer output -. Resuming a failed push -. Performing a production 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>> +* <<_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 @@ -35,12 +37,12 @@ Contact:: Persons:: bowlofeggs Location:: - Phoenix + iad2 Servers:: - * bodhi-backend01.phx2.fedoraproject.org (composer) + * bodhi-backend01.iad2.fedoraproject.org (composer) * os.fedoraproject.org (web front end and backend task workers for 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 workers for non-compose tasks) Purpose:: @@ -49,7 +51,7 @@ Purpose:: == Adding a new pending release 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: @@ -129,7 +131,7 @@ Uncomment or remove the lines related to pre and post beta polcy == 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: .... @@ -141,7 +143,7 @@ $ sudo rbac-playbook openshift-apps/bodhi.yml == 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 @@ -228,9 +230,9 @@ playbook: sudo rbac-playbook -l staging groups/bodhi-backend.yml .... -In the [.title-ref]#os_masters inventory# -_, -edit the `bodhi_version` setting it to the version you wish to deploy to +In the +https://pagure.io/fedora-infra/ansible/blob/main/f/inventory/group_vars/os_masters_stg[os_masters inventory], +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, I would set that varible like this: @@ -261,9 +263,9 @@ playbook: sudo rbac-playbook groups/bodhi-backend.yml -l bodhi-backend .... -In the [.title-ref]#os_masters inventory# -_, -edit the `bodhi_version` setting it to the version you wish to deploy to +In the +https://pagure.io/fedora-infra/ansible/blob/main/f/inventory/group_vars/os_masters[os_masters inventory], +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, 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 You can easily add notification messages to the front page of bodhi -using the [.title-ref]#frontpage_notice# option in -[.title-ref]#ansible/roles/bodhi2/base/templates/production.ini.j2#. If +using the _frontpage_notice_ option in +_ansible/roles/bodhi2/base/templates/production.ini.j2_. If 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. == Using the Bodhi Shell to modify updates by hand @@ -319,9 +321,9 @@ sudo pshell /etc/bodhi/production.ini >>> execfile('shelldb.py') .... -At this point you have access to a [.title-ref]#db# SQLAlchemy Session -instance, a [.title-ref]#t# [.title-ref]#transaction# module, and -[.title-ref]#m# for the [.title-ref]#bodhi.models#. +At this point you have access to a _db_ SQLAlchemy Session +instance, a _t_ _transaction module_, and +_m_ for the _bodhi.models_. .... # Fetch an update, and tweak it as necessary. @@ -399,16 +401,16 @@ Custom Variables: === Atomic OSTree compose failure -If the Atomic OSTree compose fails with some sort of [.title-ref]#Device -or Resource busy# error, then run [.title-ref]#mount# to see if there -are any stray [.title-ref]#tmpfs# mounts still active: +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 [.title-ref]#umount -/var/lib/mock/fedora-22-updates-testing-x86_64/root/var/tmp/rpm-ostree.bylgUq# +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 @@ -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 -worked around by removing the [.title-ref]#.repocache# directory and +worked around by removing the _.repocache_ directory and resuming the push: ....