Open alexjfisher opened 4 years ago
It's worse than I thought. prometheus::server
is actually missing plenty of parameters and prometheus::config
mixes getting server specific values from prometheus
and prometheus::server
:(
How about something like...
Option 1:
prometheus
and into prometheus::global
. Defaults for these options could still come from hiera where they are OS specific. Other than that, it would behave a little bit like how params.pp did before. Users would be expected to declare it (or use their own hiera) if they wanted to change any of these options though.prometheus
or prometheus::server
(maybe the later to signify a clean break from the old structure).My impression is that you can use exporters on a machine without the server itself so I don't think you can get rid of prometheus::server
. Since it does make sense to have some common defaults, I think getting rid of prometheus
and introducing prometheus::global
makes the most sense.
At the moment, I think it's very confusing that there are two interfaces to
prometheus::server
. You can declare that class directly, or declare the base class withmanage_prometheus_server => true
.prometheus::server
and all the node exporters inheritprometheus
for common defaults, (they use to inherit from params.pp), but it's very difficult to see whatprometheus
parameters are common defaults and which ones are just for wrappingprometheus::server
.I was planning to add puppet strings docs, but don't think we should be doing that in two places. I'm happy to spend time refactoring, but am looking for ideas for the best way forward.