Ori.livneh has uploaded a new change for review.
https://gerrit.wikimedia.org/r/125025
Change subject: Corrections to the inline documentation for role::graphite
......................................................................
Corrections to the inline documentation for role::graphite
* The number of Carbon cache instances is now six, not four.
* Removed TODO about automatically generating the list of destinations. I've
thought about this before and was prompted to think about it again by
I57d5d85bf. I agree that it's good to be DRY -- configurations that have to
match in value should ideally be specified once, to avoid the possibility of
error due to mismatching values. But I think the ways of achieving that here
entail adding a layer of abstraction on the Graphite module, and that would
come at the cost of diminished flexibility (if we design the module to
generate configs for a single-node Graphite setup) or added complexity (if we
design the module so that it is able to generate configuration files for
single-node and multi-node setup), which would in turn mean a greater surface
for bugs. So I don't think it's warranted.
Note that this is the decision Graphite itself made: its config parser could
also be made smart enough to automatically determine the set of caches a
relay instance should forward to. But Graphite declines to be too clever
about this, and I think it's the right call, to be honest.
Change-Id: Icc7fb9adb81eae13dcf532bbd25aede74d94289b
---
M manifests/role/graphite.pp
1 file changed, 2 insertions(+), 3 deletions(-)
git pull ssh://gerrit.wikimedia.org:29418/operations/puppet
refs/changes/25/125025/1
diff --git a/manifests/role/graphite.pp b/manifests/role/graphite.pp
index 5775d90..ea67c66 100644
--- a/manifests/role/graphite.pp
+++ b/manifests/role/graphite.pp
@@ -46,8 +46,8 @@
},
# All metric data goes through a single carbon-relay instance, which
- # forwards each data point to one of four carbon-cache instances,
using a
- # consistent hash ring to distribute the load.
+ # forwards each data point to one of six carbon-cache instances, using
+ # a consistent hash ring to distribute the load.
#
# Why is this necessary? Because carbon-cache is CPU-bound, and the
Python
# GIL prevents it from utilizing multiple processor cores efficiently.
@@ -106,7 +106,6 @@
enable_udp_listener => 'true',
relay_method => 'consistent-hashing',
destinations => [
- #TODO: fetch the destinations list from carbon_settings
'127.0.0.1:2104:a',
'127.0.0.1:2204:b',
'127.0.0.1:2304:c',
--
To view, visit https://gerrit.wikimedia.org/r/125025
To unsubscribe, visit https://gerrit.wikimedia.org/r/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: Icc7fb9adb81eae13dcf532bbd25aede74d94289b
Gerrit-PatchSet: 1
Gerrit-Project: operations/puppet
Gerrit-Branch: production
Gerrit-Owner: Ori.livneh <[email protected]>
_______________________________________________
MediaWiki-commits mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-commits
