---
# Define resources for this group of hosts here. 
jobrunner: false
epelmasher: false

lvm_size: 40000
mem_size: 16384
num_cpus: 4

# Do not use testing repositories on production
testing: False

# 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,sysadmin-bodhi,sysadmin-veteran
sudoers: "{{ private }}/files/sudo/00releng-sudoers"

# 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
bodhi_signed_handler_enabled: False

# These are consumed by a task in roles/fedmsg/base/main.yml
fedmsg_certs:
- service: shell
  owner: root
  group: sysadmin
  can_send:
  - logger.log
- 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.reach
  - 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.