---
# Define resources for this group of hosts here. 
lvm_size: 20000
mem_size: 6144
num_cpus: 4

# for systems that do not match the above - specify the same parameter in
# the host_vars/$hostname file

tcp_ports: [
    # These four ports are for outbound fedmsg
    3000, 3001, 3002, 3003,
]

fas_client_groups: sysadmin-noc,sysadmin-fedimg,sysadmin-releng,sysadmin-veteran

fedmsg_debug_loopback: True

# These people get told when something goes wrong.
fedmsg_error_recipients:
- sysadmin-fedimg-members@fedoraproject.org

# 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: autocloud
  owner: root
  group: fedmsg
  can_send:
  - autocloud.image
  - autocloud.image.running
  - autocloud.image.success
  - autocloud.image.failed
  - autocloud.image.queued

# For the MOTD
csi_security_category: Moderate
csi_primary_contact: Cloudmeisters - sysadmin-fedimg-members@fedoraproject.org
csi_purpose: Run the autocloud testing backend
csi_relationship: |
    This runs one of the two autocloud testing backends

    This host relies on:
    - A postgres db server running on db01.  The db is called 'autocloud'.
      The two autocloud-backend nodes populate that database with results.
    - fedmsg messages produced by koji indicating that new images were built.
    - queries to koji directly to download that content.

    Running locally we have:
    - fedmsg-hub which receives the initial notification from koji via fedmsg.
    - redis, which stores a work queue populated by fedmsg
    - the autocloud daemon, which pulls work from the redis queue and uses tunir
      to test images in vagrant.

    There's a cronjob that kills vagrant every 10 minutes if it got stuck on the
    last test.
