Files
fedora-infra_ansible/inventory/group_vars/bodhi2

107 lines
3.6 KiB
Plaintext

---
# Define resources for this group of hosts here.
jobrunner: false
epelmasher: false
lvm_size: 40000
mem_size: 16384
num_cpus: 4
# for systems that do not match the above - specify the same parameter in
# the host_vars/$hostname file
host_group: bodhi2
# Definining these vars has a number of effects
# 1) mod_wsgi is configured to use the vars for its own setup
# 2) iptables opens enough ports for all threads for fedmsg
# 3) roles/fedmsg/base/ declares enough fedmsg endpoints for all threads
wsgi_fedmsg_service: bodhi
wsgi_procs: 4
wsgi_threads: 15
tcp_ports: [ 80 ]
# Neeed for rsync from log01 for logs.
custom_rules: [ '-A INPUT -p tcp -m tcp -s 10.5.126.13 --dport 873 -j ACCEPT', '-A INPUT -p tcp -m tcp -s 192.168.1.59 --dport 873 -j ACCEPT' ]
fas_client_groups: sysadmin-noc
# These set a config value in /etc/fedmsg.d/, see roles/bodhi2/base/
# frontend nodes won't run either of these
bodhi_masher_enabled: False
bodhi_updates_handler_enabled: False
# These are consumed by a task in roles/fedmsg/base/main.yml
fedmsg_certs:
- service: shell
owner: root
group: sysadmin
- service: bodhi
owner: root
group: bodhi
can_send:
- bodhi.buildroot_override.tag
- bodhi.buildroot_override.untag
- bodhi.stack.delete
- bodhi.stack.save
- bodhi.update.comment
- bodhi.update.complete.testing
- bodhi.update.edit
- bodhi.update.karma.threshold
- bodhi.update.request.obsolete
- bodhi.update.request.revoke
- bodhi.update.request.stable
- bodhi.update.request.testing
- bodhi.update.request.unpush
# Things that only the mash does - not the web UI
#- bodhi.mashtask.complete
#- bodhi.mashtask.mashing
#- bodhi.mashtask.start
#- bodhi.mashtask.sync.done
#- bodhi.mashtask.sync.wait
#- bodhi.errata.publish
#- bodhi.update.eject
# Rsync messages that get run from somewhere else entirely.
#- bodhi.updates.epel.sync
#- bodhi.updates.fedora.sync
# For the MOTD
csi_security_category: Moderate
csi_primary_contact: Bodhi Admins bodhiadmin-members@fedoraproject.org
csi_purpose: Run the Bodhi mod_wsgi app for bodhi.fedoraproject.org
csi_relationship: |
The apache/mod_wsgi app is the only thing really running here.
The mashing of repos is handled by the bodhi-backend node(s).
* This host relies on:
* db01 for its database.
* it doesn't have a networked cache of its own.. but it keeps a local
cache in /var/cache/bodhi/
* taksotron (resultsdb) for getting status-check results (gating updates).
* It also depends on these things, but we're trying to move them exclusively
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
* the wiki for getting information about QA "Test Cases"
* It provides a website that, on the client side depends on:
* datagrepper queries to show the newfeed on the frontpage
* the websocket server for popup notifications of others' activity.
* the fedora-packages JSON api for suggesting package search results
* Quite a few things rely on this webapp
* Taskotron historically would comment on updates about the status of
their checks.
* Blockerbugs checks bodhi for lists of updates.
* fedora-packages will try to query bodhi for the release status of
updates.
* fedora-hubs has some widgets that display bodhi update information.
* fedora-easy-karma, abrt, 'fedpkg update', an eclipse plugin and other
client tools make queries to the bodhi webapp here.