blob: bd1255f17bb17652ce7e7da300679a1f6b2ab491 (
plain)
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
42
43
44
45
46
47
48
49
50
51
|
---
lvm_size: 20000
mem_size: 6144
num_cpus: 2
freezes: false
# for systems that do not match the above - specify the same parameter in
# the host_vars/$hostname file
tcp_ports: [ 3000, 3001, 3002, 3003 ]
fas_client_groups: sysadmin-noc,sysadmin-datanommer,sysadmin-veteran
# 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: bugzilla2fedmsg
owner: root
group: fedmsg
can_send:
- bugzilla.bug.new
- bugzilla.bug.update
# For the MOTD
csi_security_category: Low
csi_primary_contact: Fedmsg admins - sysadmin-datanommer-members@fedoraproject.org
csi_purpose: Run the bugzilla2fedmsg bridge to forward RH messages onto fedmsg
csi_relationship: |
A 'moksha-hub' daemon is the only thing really running here. (Don't confuse
that with the 'fedmsg-hub' running on most of our other backend machines.)
The bugzilla2fedmsg package provides a plugin to the moksha-hub that
connects out over the STOMP protocol to a 'fabric' of JBOSS FUSE brokers
living in the Red Hat DMZ. We authenticate with a cert/key pair that is
kept in /etc/pki/fedmsg/. Those brokers should push bugzilla events over
STOMP to our moksha-hub daemon. When a message arrives, we query bugzilla
about the change to get some 'more interesting' data to stuff in our
payload, then we sign the message using a fedmsg cert and fire it off to the
rest of our bus.
This service has no database, no memcached usage. It depends on those STOMP
brokers and being able to query bugzilla.rh.com.
STOMP config: /etc/moksha/production.ini
fedmsg config: /etc/fedmsg.d/
certs: /etc/pki/fedmsg
code: /usr/lib/python2.7/site-packages/bugzilla2fedmsg.py
|
