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 On Tuesday, October 20, 2020 at 11:30:58 PM UTC+2 Julien Pivotto wrote: > On 20 Oct 14:13, Roman Danko wrote: > > 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. > > 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 [email protected]. > > 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 > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/25e58ae9-cb4c-4522-9632-7d058b505ae4n%40googlegroups.com.
