Bug#894131: [pkg-go] Bug#894131: prometheus-alertmanager: New upstream release 0.14.0 available. Please package and backport to stretch.
Daniel, On 27/03/18 09:06, Daniel Swarbrick wrote: > Debian currently has Haskell Platform 2014.2.0.0 (GHC 7.8.3), so to > build the version of Elm used by Alertmanager, Debian would most likely > first have to update their Haskell. And so it continues... Ah, nice.. > I think you idea of stripping away the UI and replacing it with > something non-standard is not a good idea, because Debian will become > known as "that distro" which has non-standard Prometheus packages. > People will either use a different distro, or run it in Docker, or > something else - in any case, your work will have been for nothing. Well, I don't really care about being not standard in that sense. The standard is to run docker packages downloaded from untrusted sources, fwiw. My objective is to provide sysadmins that align with the Debian worldview with a working Prometheus stack. I have had already to deviate from the standard in a few things, for example: kubernetes support was removed from the prometheus Debian package because it is unmaintainable, until the k8s people get their act together. > What exactly in Debian policy is preventing us shipping Alertmanager > built as intended by upstream? I don't remember which section in the Policy that is. But those generated files are not source code, and therefore there is a requirement to (re)build them from source. It is the same as i was shipping a pre-compiled .so file. > Would it be an option to _decompress_ the gzipped & hex-encoded blobs > from Alertmanager's ui/bindata.go back to their sources and package > those? Looking at the file, that would produce these files: This is not really a problem, I am not shipping the binary blob (because I want to reuse libraries already present in debian). The problem is the generated code, which is not source code (preferred form of modification). -- Martín Ferrari (Tincho)
Bug#894131: [pkg-go] Bug#894131: prometheus-alertmanager: New upstream release 0.14.0 available. Please package and backport to stretch.
Martin, The Alertmanager UI requires Elm 0.18 (as specified in its elm-package.json). Over at https://github.com/elm-lang/elm-platform#1-get-haskell-working, they state that Elm <= 0.16 should build with GHC 7.8. I take this to mean that later versions of Elm require a later version of GHC, and indeed they mention that their developers mostly use GHC 7.10. Debian currently has Haskell Platform 2014.2.0.0 (GHC 7.8.3), so to build the version of Elm used by Alertmanager, Debian would most likely first have to update their Haskell. And so it continues... I think you idea of stripping away the UI and replacing it with something non-standard is not a good idea, because Debian will become known as "that distro" which has non-standard Prometheus packages. People will either use a different distro, or run it in Docker, or something else - in any case, your work will have been for nothing. What exactly in Debian policy is preventing us shipping Alertmanager built as intended by upstream? Would it be an option to _decompress_ the gzipped & hex-encoded blobs from Alertmanager's ui/bindata.go back to their sources and package those? Looking at the file, that would produce these files: // Code generated by go-bindata. // sources: // ui/app/script.js // ui/app/index.html // ui/app/favicon.ico // ui/app/lib/bootstrap-4.0.0-alpha.6-dist/css/bootstrap.min.css // ui/app/lib/bootstrap-4.0.0-alpha.6-dist/css/bootstrap.min.css.map // ui/app/lib/font-awesome-4.7.0/css/font-awesome.css // ui/app/lib/font-awesome-4.7.0/css/font-awesome.min.css // ui/app/lib/font-awesome-4.7.0/fonts/FontAwesome.otf // ui/app/lib/font-awesome-4.7.0/fonts/fontawesome-webfont.eot // ui/app/lib/font-awesome-4.7.0/fonts/fontawesome-webfont.svg // ui/app/lib/font-awesome-4.7.0/fonts/fontawesome-webfont.ttf // ui/app/lib/font-awesome-4.7.0/fonts/fontawesome-webfont.woff // ui/app/lib/font-awesome-4.7.0/fonts/fontawesome-webfont.woff2 Best, Daniel
Bug#894131: [pkg-go] Bug#894131: prometheus-alertmanager: New upstream release 0.14.0 available. Please package and backport to stretch.
Hi Daniel, On 26/03/18 20:34, Daniel Swarbrick wrote: > I was a bit too hasty in my previous reply. It appears that Alertmanager > compresses and encodes all the web UI assets a Go "blob" > (https://github.com/prometheus/alertmanager/blob/master/ui/bindata.go). > Elm libraries are only needed if you intend to hack / develop the web UI. Exactly. Prometheus itself does the same thing. The approach I took was to remove the blob and patch the web serving code to read the files directly from disk, and then to do al the JS processing at build time from source. I would do the same for alertmanager, but for that I need a working Elm stack to generate the JS from source, otherwise it is a serious violation of Debian policy. > I just built a fully functional alertmanager binary from a git clone, > with no Elm or Haskell or Node.js anywhere to be seen on my system. This > is why I mistakenly thought that the aforementioned RPMs had stripped > the UI completely, when in fact it is simply compiled into the > alertmanager binary. > > Does this simplify things somewhat? I suppose it just leaves the > vendored Go libs as a possible sticking point. Vendoring Go libs would not be a direct violation of policy, but it is something we try hard to avoid as it becomes a maintenance problem. Vendoring pre-generated pre-minified code, on the other hand, is not possible in Debian, and that's how we ended in the current situation :-) It is because of this that I thought of stripping the UI away, and replacing it with something bare-bones. This would not be that difficult to do, it is just a matter of writing some html and JS. If you could help me with that, I would take care of integrating the replacement UI, and I could get a new release out of the door pretty quickly. -- Martín Ferrari (Tincho)
Bug#894131: [pkg-go] Bug#894131: prometheus-alertmanager: New upstream release 0.14.0 available. Please package and backport to stretch.
Martin, I was a bit too hasty in my previous reply. It appears that Alertmanager compresses and encodes all the web UI assets a Go "blob" ( https://github.com/prometheus/alertmanager/blob/master/ui/bindata.go). Elm libraries are only needed if you intend to hack / develop the web UI. I just built a fully functional alertmanager binary from a git clone, with no Elm or Haskell or Node.js anywhere to be seen on my system. This is why I mistakenly thought that the aforementioned RPMs had stripped the UI completely, when in fact it is simply compiled into the alertmanager binary. Does this simplify things somewhat? I suppose it just leaves the vendored Go libs as a possible sticking point. Best, Daniel
Bug#894131: [pkg-go] Bug#894131: prometheus-alertmanager: New upstream release 0.14.0 available. Please package and backport to stretch.
Hi Martin, I just had a quick look at the docs for build Elm from source, and it looks like a pretty direct journey to npm hell. I'm pretty out of touch with modern web development, so I'm not sure how much help I can be be in terms of packaging Elm. I can suggest a couple of alternatives. One would be to ship Alertmanager without any UI whatsoever, as has been done in the unofficial RPMs at https://packagecloud.io/prometheus-rpm/release. This obviously affects the end user experience quite substantially, but ultimately does not detract from Alertmanager's main functionality. The other option would be to bundle the necessary Elm libs with Alertmanager itself, but I suspect this violates Debian packaging policy. Even if somebody were able to package Elm and make it a dependency of the Alertmanager package, those JS libs need to somehow be served by the integrated web server in Alertmanager. I would normally expect to see an Apache or Nginx config snippet or .htaccess with some kind of directory alias, but obviously that won't fly in this case. Symlinks to directories? I don't think I've seen many (if any) Debian packages do that. Best, Daniel
Bug#894131: [pkg-go] Bug#894131: prometheus-alertmanager: New upstream release 0.14.0 available. Please package and backport to stretch.
Daniel, On 26/03/18 17:31, Daniel Swarbrick wrote: > Current Debian packages for prometheus-alertmanager are extremely out of > date. The web UI and (undocumented / unstable) API has changed > considerably in the ten versions that have been released since 0.6.2, > along with many bugfixes. I know, this is a pretty sad state. The problem is that upgrading the alertmanager requires packaging and uploading many new packages, as they started using the Elm system for the UI, and no part of it is in Debian. The alternative to this is to develop a patch that will provide an barebones UI without the dynamic JS generated with Elm. I am maintaining most of the prometheus ecosystem by myself, so I have not been able to do any of this. If you have the resources to help, you would be most welcomed! -- Martín Ferrari (Tincho)
