Split bodhi-backend stuff out amongst the two nodes.

This commit is contained in:
Ralph Bean 2015-09-02 17:02:54 +00:00
parent f2ef4e8aae
commit b9c701140a
6 changed files with 52 additions and 26 deletions

View file

@ -22,6 +22,9 @@
- name: restart fedmsg-hub
command: /usr/local/bin/conditional-restart.sh fedmsg-hub fedmsg-hub
# Note that, we're cool with arbitrary restarts on bodhi-backend02, just
# not bodhi-backend01. 01 is where the releng/mash stuff happens and we
# don't want to interrupt that.
when: inventory_hostname != 'bodhi-backend01.phx2.fedoraproject.org'
- name: restart fedmsg-irc

View file

@ -72,26 +72,4 @@ nfs_mount_opts: "rw,hard,bg,intr,noatime,nodev,nosuid,nfsvers=3"
fas_client_groups: sysadmin-releng
sudoers: "{{ private }}/files/sudo/arm-releng-sudoers"
# For the MOTD
csi_security_category: Medium
csi_primary_contact: Releng Admins sysadmin-releng-members@fedoraproject.org
csi_purpose: Run the Bodhi masher.
csi_relationship: |
The mashing of repos here happens as part of the 'fedmsg-hub' daemon. Check
logs with 'journalctl -u fedmsg-hub'. Check the bodhi masher docs/code for
more detail on what it does:
https://github.com/fedora-infra/bodhi/blob/develop/bodhi/consumers/masher.py
* This host relies on:
* db01 for its database, which is shares with the bodhi2 frontend nodes.
* An NFS mount of koji data in /mnt/koji/
* The fedmsg bus for triggering mashes.
* XMLRPC calls to koji for tagging and untagging updates.
* bugzilla for posting comments about status changes
* the wiki for getting information about QA "Test Cases"
* taksotron (resultsdb) for getting status-check results (gating updates).
* No other systems rely directly on this host. Everything depends on it
indirectly for the creation of new updates repos (which get synced out to
the master mirror for distribution.
## XXX - note that the csi_ stuff is kept at the host_vars/ level.

View file

@ -79,7 +79,7 @@ csi_relationship: |
* taksotron (resultsdb) for getting status-check results (gating updates).
* It also depends on these things, but we're trying to move them exclusively
to the backend.
to bodhi-backend02.
* koji for tagging and untagging updates and listing candidate builds
* bugzilla, for getting bug title information and for posting comments
about status changes

View file

@ -8,3 +8,27 @@ volgroup: /dev/vg_Server
eth0_ip: 10.5.125.135
eth1_ip: 10.5.127.61
vmhost: bvirthost10.phx2.fedoraproject.org
# For the MOTD
csi_security_category: Medium
csi_primary_contact: Releng Admins sysadmin-releng-members@fedoraproject.org
csi_purpose: Run the Bodhi masher.
csi_relationship: |
The mashing of repos here happens as part of the 'fedmsg-hub' daemon. Check
logs with 'journalctl -u fedmsg-hub'. Check the bodhi masher docs/code for
more detail on what it does:
https://github.com/fedora-infra/bodhi/blob/develop/bodhi/consumers/masher.py
* This host relies on:
* db01 for its database, which is shares with the bodhi2 frontend nodes.
* An NFS mount of koji data in /mnt/koji/
* The fedmsg bus for triggering mashes.
* XMLRPC calls to koji for tagging and untagging updates.
* bugzilla for posting comments about status changes
* the wiki for getting information about QA "Test Cases"
* taksotron (resultsdb) for getting status-check results (gating updates).
* No other systems rely directly on this host. Everything depends on it
indirectly for the creation of new updates repos (which get synced out to
the master mirror for distribution.

View file

@ -8,3 +8,23 @@ volgroup: /dev/vg_bvirthost06
eth0_ip: 10.5.125.136
eth1_ip: 10.5.127.62
vmhost: bvirthost06.phx2.fedoraproject.org
# For the MOTD
csi_security_category: Low
csi_primary_contact: Bodhi Admins bodhiadmin-members@fedoraproject.org
csi_purpose: Run the Bodhi UpdatesHandler and other backend processes
csi_relationship: |
This host handles all of the bodhi backend stuff **except** for mashing.
https://github.com/fedora-infra/bodhi/blob/develop/bodhi/consumers/
* This host relies on:
* db01 for its database, which is shares with the bodhi2 frontend nodes.
* The fedmsg bus for triggering work.
* XMLRPC calls to koji for tagging and untagging updates.
* bugzilla for posting comments about status changes
* the wiki for getting information about QA "Test Cases"
* No other systems rely directly on this host. Everything depends on it
indirectly for the creation of new updates repos (which get synced out to
the master mirror for distribution.

View file

@ -1,6 +1,7 @@
config = dict(
# TODO -- we're thinking about moving this to bodhi-backend02
{% if inventory_hostname.startswith('bodhi-backend01') %}
# Note, the masher runs on bodhi-backend01, but this
# runs on bodhi-backend02 (separation of concerns).
{% if inventory_hostname.startswith('bodhi-backend02') %}
updates_handler=True,
{% else %}
updates_handler=False,