1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
|
---
# Define resources for this group of hosts here.
lvm_size: 20000
mem_size: 2048
num_cpus: 2
host_group: pdc-backend
# for systems that do not match the above - specify the same parameter in
# the host_vars/$hostname file
tcp_ports: []
fas_client_groups: sysadmin-noc,sysadmin-releng,sysadmin-datanommer,sysadmin-mbs,sysadmin-veteran
# See the host_vars files for the value of fedmsg_error_recipients here
csi_security_category: Moderate
csi_primary_contact: Ralph Bean <rbean@redhat.com>
csi_purpose: fedmsg-hub daemon that ferries data from fedmsg to PDC.
csi_relationship: |
NOTICE - The three pdc-backend do *different* things. They all run a
fedmsg-hub daemon that loads the pdc-updater consumer plugin. However, the
pdc-updater plugin is configured to do different things in each place.
On pdc-updater01, the compose handler is enabled which listens for new pungi
composes, and stores them in PDC. Fedora QE uses this data. The consumer
has only a single thread enabled to avoid OOMing itself with more than one
compose at a time.
On pdc-updater02, the modularity handlers are enabled which listen for MBS
activity, and store that in PDC. pdc-updater02 also hosts the retirement
handler which listens to dist-git for new dead.package files, and propagates
the retirement to PDC (by prematurely EOLing the branch). Multiple threads are
enabled so that it can work more efficiently on these smaller tasks.
On pdc-updater03, the dep chain handlers are enabled which listen for koji
messages and store dep chain information in PDC, like what rpms depend on what
other rpms at build time, and what containers depend on what rpms, etc..
Multiple threads are enabled so that it can work more efficiently on these
smaller tasks.
|
