Repository navigation
Support building Linux distribution packages #93
Description
Activity
I'm wary of this. Building a package that works on your own systems is easy. Building packages that work on the myriad of variants of distros out there and the support that comes from that variation is not.
Reacted by Callum StyanI think it would certainly be an advantage for the project to release packages for a number of reasons and any fears can easily be alleviated.
- Makes Prometheus more accessible to the masses (easier to install and update)
- installation / setup Consistency
Ubuntu & Debian
Standalone Linux Binaries
Redhat & CentosI don't think support should be any greater than that to be honest and would limit to .deb .rpm - once the first generic package has been created then subsequent upgrade will fall in-line so there will be little in terms of variance.
I am certainly more than happy to help test and feedback, but this is defiantly a good thing.
Thanks.
Pete
Reacted by Gabriele Iannetti and Joseph Sirianni@VR6Pete I don't think you appreciate the nature of the variation. At the simplest, what if some distros are using SysV init, others systmed and some upstart? Different distros put things in different places with different policies, and that's before you even get to per-site variations.
If you want Debian packages for example, Debian already have those and they follow their policies.
I have been packaging software for over 10 years so know exactly the type of challenges you can face, but simply cannot dismiss it on that basis, and you have to start somewhere so to speak and many other vendors have dealt with this type of issue and have released working binaries.
A good starting point would be to look at how Grafana have done - I don't think the wheel needs to be re-invented here.
It's not a matter of releasing working binaries, it's about working packages.
I would not consider Grafana an example of good packaging, as they still have to get service management right.
@brian-brazil The Debian package builder, for example, automatically handles various init systems, this is pretty easy to deal with these days.
The problem with Debian is they don't follow our vendoring, or our release cycle very closely. I would much prefer to provide our own packages, so users can follow our release cycle more easily.
Reacted by Danny Kulchinsky, mattrussi and FredbMany other projects generate nightly builds in a number of package formats successfully, I wouldn’t be too concerned.
Yes very useful, I'm using the latest grafana version with an old Prometheus
Continuous Integration to be facilitated (very) by packagesThis might be easier to integrate: https://github.com/goreleaser/nfpm#usage-as-lib
I am willing to work on this.
Reacted by Moritz SternemannCount me in for debian related packaging.
Just my two cents: this seem ill-advised to me. Such code would be best kept in distributions, as they are the ones who make the ultimate decisions about how to package things. For example, many distros have their own re-usable code for e.g. "a rust app", or "an npm module" or such. So the best that could be done is to provide a uniform way to build exporters (essentially done, but of course ongoing), so that distributions can build such a re-usable module for exporters. But there might always be exceptions, and they should ultimately be handled at distribution level.
The problem is distributions definitely can't keep up with the pace of of our development. Also they make questionable choices like re-packaging all dependencies, ignoring the go.mod files. This has caused several bugs, for example Debian included an incorrect procfs package version for the node_exporter. This caused a couple of bugs that were fixed to be released into stable.
I don't see how any of that would change by providing a way to build packages. The distributions that make questionable choices will still make those and not package what you provide. If you just provide packages for download, people will stick to old versions (because their package manager doesn't update them) - another cause for unnecessary bug reports. If you really intend to run a package repository, I would tip my hat, but that is a pretty substantial amount of work.
Also, what exactly would be the scope here? Which distributions? Which derivatives? Which versions? etc...
We planned to combine our packages with distribution publishing via something like packagecloud.
I think Linux package support would be a great addition, even if it means they are served from the releases page. Installing Prometheus onto a systemd based server by hand is not fun.
I was able to implement a solution today for a personal project. Using Goreleaser, but I am sure Promu can be extended to support building linux packages with the nFPM package that Goreleaser uses.
My example is a basic distribution agnostic solution with inspec (cinc) tests for install and uninstall.
If anyone is interested, ill leave this PR open.
Thanks. I think the main issue is that your implementation adds a lot of boiler plate. We have something like 50 exporter repos that are downstream from promu. Not to mention any non-official exporters that use our build system.
We want to be able to produce packages with the minimum amount of downstream work possible.
Is this effort still ongoing? If not, could i help?
For reference, https://github.com/Shopify/toxiproxy shows a goreleaser github config doesn't need to include a huge amount of boilerplate.
This might be easier to integrate: goreleaser/nfpm#usage-as-lib
@SuperQ Is there any reason or benefit of continue maintain and adding functionally to promu, instead using goreleaser?
Aside from unix packages (I'm use it here) , goreleaser also supports building container images without a Dockerfile (here) and sign them (ref). It supports building via go proxy conditionally, resulting into a working go_build_info metric for exporters.
I understand, that there is a lot of downstream work to migrate. However it may reduce overall maintainer work and keeping the focus on our core solutions.
I expect, that switch to goreleaser would enrich the maintainer experience in each downstream project as well.
We actually discussed migrating to goreleaser a while back. I'm generally in favor.
There were some missing features at the time. Mostly around supporting our Makefile workflows and CGO that is use in a few places like node_exporter.
Reacted by Jan-Otto Kröpke
It would be useful to add a
packagescommand that would builddebandrpmformat packages for various Linux distributions.We could use native packaging utilties, or something fpm.