infra-docs-fpo/modules/sysadmin_guide/pages/blockerbugs.adoc
Michal Konečný 6016070199 Review blockerbugs SOP
Signed-off-by: Michal Konečný <mkonecny@redhat.com>
2021-08-17 16:08:11 +02:00

156 lines
3.8 KiB
Text

= Blockerbugs Infrastructure SOP
https://pagure.io/fedora-qa/blockerbugs[Blockerbugs] is an app developed
by Fedora QA to aid in tracking items related to release blocking and
freeze exception bugs in branched Fedora releases.
== Contents
* <<_contact_information>>
* <<_file_locations>>
* <<_building_for_infra>>
* <<_upgrading>>
** <<_upgrade_preparation_all_upgrades>>
** <<_minor_upgrades_no_database_changes>>
** <<_major_upgrades_with_database_changes>>
== Contact Information
Owner::
Fedora QA Devel
Contact::
#fedora-qa
Location::
iad2
Servers::
blockerbugs01.iad2, blockerbugs02.iad2, blockerbugs01.stg.iad2
Purpose::
Hosting the https://pagure.io/fedora-qa/blockerbugs[blocker bug
tracking application] for QA
== File Locations
`/etc/blockerbugs/settings.py` - configuration for the app
=== Node Roles
blockerbugs01.stg.iad2::
the staging instance, it is not load balanced
blockerbugs01.iad2::
one of the load balanced production nodes, it is responsible for
running bugzilla/bodhi/koji sync
blockerbugs02.iad2::
the other load balanced production node. It does not do any sync
operations
== Building for Infra
=== Do not use mock
For whatever reason, the `epel7-infra` koji tag rejects SRPMs with the
`el7.centos` dist tag. Make sure that you build SRPMs with:
....
rpmbuild -bs --define='dist .el7' blockerbugs.spec
....
Also note that this expects the release tarball to be in
`~/rpmbuild/SOURCES/`.
=== Building with Koji
You'll need to ask someone who has rights to build into `epel7-infra`
tag to make the build for you:
....
koji build epel7-infra blockerbugs-0.4.4.11-1.el7.src.rpm
....
[NOTE]
====
The fun bit of this is that `python-flask` is only available on `x86_64`
builders. If your build is routed to one of the non-x86_64, it will
fail. The only solution available to us is to keep submitting the build
until it's routed to one of the x86_64 builders and doesn't fail.
====
Once the build is complete, it should be automatically tagged into
`epel7-infra-stg` (after a ~15 min delay), so that you can test it on
blockerbugs staging instance. Once you've verified it's working well,
ask someone with infra rights to move it to `epel7-infra` tag so that
you can update it in production.
== Upgrading
Blockerbugs is currently configured through ansible and all
configuration changes need to be done through ansible.
=== Upgrade Preparation (all upgrades)
Blockerbugs is not packaged in epel, so the new build needs to exist in
the infrastructure stg repo for deployment to stg or the infrastructure
repo for deployments to production.
See the blockerbugs documentation for instructions on building a
blockerbugs RPM.
=== Minor Upgrades (no database changes)
Run the following on *both* `blockerbugs01.iad2` and
`blockerbugs02.iad2` if updating in production.
[arabic]
. Update ansible with config changes, push changes to the ansible repo:
+
....
roles/blockerbugs/templates/blockerbugs-settings.py.j2
....
. Clear yum cache and update the blockerbugs RPM:
+
....
yum clean expire-cache && yum update blockerbugs
....
. Restart httpd to reload the application:
+
....
service httpd restart
....
=== Major Upgrades (with database changes)
Run the following on *both* `blockerbugs01.phx2` and
`blockerbugs02.phx2` if updating in production.
[arabic]
. Update ansible with config changes, push changes to the ansible repo:
+
....
roles/blockerbugs/templates/blockerbugs-settings.py.j2
....
. Stop httpd on *all* relevant instances (if load balanced):
+
....
service httpd stop
....
. Clear yum cache and update the blockerbugs RPM on all relevant
instances:
+
....
yum clean expire-cache && yum update blockerbugs
....
. Upgrade the database schema:
+
....
blockerbugs upgrade_db
....
. Check the upgrade by running a manual sync to make sure that nothing
unexpected went wrong:
+
....
blockerbugs sync
....
. Start httpd back up:
+
....
service httpd start
....