blob: d58091de32bae8aae90eadb0af541b991a49a055 (
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
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
|
---
# 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.
|
