Introducing static config mapping 1:1 comand-line flags

[Roman Danko]

I use promethes installed by cloudalchemy.prometheus ansible role, which setups systemd service. I would like to contribute to building rpm package for prometheus, which would enable to use system packager to install & update. There is already present project which creates packages for various proemtheus components & exporters https://github.com/lest/prometheus-rpm. They are doing great work however I have some improvements, which are impossible without support from prometheus itself. Specifically I would like to get rid of using /etc/default as config, which is legacy way and should be done like proposed in http://0pointer.net/blog/projects/on-etc-sysinit.html. Long story short, either by overriding systemd service params or by loading config from /etc ny progrqm itself. I think that first one would be ok if configuratiom necessary to override wasn't spaghetti one-liner(command-line flags). I know about philosophy around keeping hot-reloadable config options in file and other one as comand-line args, however this could be done by separate config which would not be hot-reloadable. Treaefik use two configs for exactly same reason. Why not do it this way and get closer to be more convenient for users which run prometheus natively without containers.

[Julien Pivotto]

Hello Roman,

I am familiar with lest/prometheus-rpm, they are doing a great work
here. However, implementing it as is for Prometheus seems to be a no-go
for me as building spec files and sysinit files is not maintainable in
the long term.

Instead, the idea that I have, and which is in a corner of my head for a
long time, is to implement deb and rpm packages build within promtool by
using https://github.com/goreleaser/nfpm as a library. That way would be
more sustainable over the long term, as we have a lot of official
exporters which would benefit from it.

Instead of creating another configuration file, I think we should work
to get more of them reloadable into files. I do like the semantic of
'config options can't be reloaded', but we could improve that and make
a lot of them hot-reloadable. However, my attempt to start doing so was
stopped early[1], so it is in the freezer until we start discussing
Prometheus 3.x

[1]: https://github.com/prometheus/prometheus/pull/7611

>
> --
> You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/b4a803a1-22c2-4d49-8121-cd0fce82b1fbn%40googlegroups.com.


--
Julien Pivotto
@roidelapluie

[Roman Danko]

Hello Julien,

thanks for the feedback, you mentioned some really interesting informations. I’ll just narrow my idea for further discussion. 

I’m focusing on the design of systemd service for prometheus and not building the package itself. I don’t care who will be creating the package, currently, I know only lest/prometheus-rpm project, so I would like to enhance that. If in the future prometheus maintainers decide to build it, I’ll be glad for it.

I studied recommend design of systemd units and it seems that the cleanest way of managing program specific config would be using config files independent from unit files. I understand that this use case may be minor compared to running in containers, which have different design principles and configuration methods. However I think that we can get as close as possible to running prometheus and distribute it through os packages. 

Probably there will always be some options which will not be hot-reloadable. Having static config options for it may be necessary for them. We can introduce it without breaking any current functionality, command-line args may have precedence over config file. Moving to dynamic options config file would be subject of prometheus 3.x according to implemeting their hot-reload ability.

--

Roman Danko

@elcomtik