Packaging the Javascript layer of Prometheus & Grafana

[Nicolas Mailhot]

Hi,

I'm currently investigating the packaging of Prometheus and Grafana in 
Fedora/Epel.

Both are cutting-edge high-visibility complex applications written in 
Go, that map well to Fedora/Epel historical sysadmin userbase
https://prometheus.io/
https://grafana.com/

I already spent a few months of work working on the Go layer, writing 
Golang-to-rpm plumbing, packaging guidelines, packaging and testing 
hundreds of spec files. It is finally looking like something that could 
end up in the distribution, even though there is still a ton of work to 
do plumbing-side to make Go packaging in Fedora simple and convenient. 
And I'd like to spend more time making this plumbing a reality.

However, at the same time, the target apps can not be used, since they 
include a javascript layer, and I haven't packaged it.

Prometheus provides a bundled copy of the javascript it needs, thus I 
supposed it could be packaged as-is, even though that is bad engineering 
and totally not what I did for the Go layer.
https://github.com/prometheus/prometheus/tree/master/web/ui/static/vendor

Grafana OTOH has a clean codebase with a build process that uses yarn to 
get third-party javascript
https://github.com/grafana/grafana/blob/master/yarn.lock

Therefore, I'm looking for help :
   1. either pointers or advice on how to package this javascript cleanly 
or
   2. ideally, people willing to take over this javascript packaging, so 
I can focus on finishing the Golang plumbing in Fedora

I suppose this is also a test if a distribution like Fedora/Epel can 
still be used to deploy the kind of apps written in 2018, or if it's 
condemned to fade and be replaced by other approaches like containers.

Regards,

[Matthias Runge]

On Wed, Aug 29, 2018 at 03:25:09PM +0200, Nicolas Mailhot wrote:
> I already spent a few months of work working on the Go layer, writing
> Golang-to-rpm plumbing, packaging guidelines, packaging and testing hundreds
> of spec files. It is finally looking like something that could end up in the
> distribution, even though there is still a ton of work to do plumbing-side
> to make Go packaging in Fedora simple and convenient. And I'd like to spend
> more time making this plumbing a reality.

Hello,

thanks for sharing, this is awesome.

While I believe, EPEL is unsuitable for this kind of applications, we
should have them in Fedora. For example prometheus is also packaged in a
recent version in Debian, while Grafana is still at version 2.6, which
is fairly old.

That being said, the way upstreams are adding/changing dependencies to
the projects and at the same time releasing multiple major and minor
releases per year makes it hard to stay on top of these projects.
Having multiple releases per year and no backports makes these kind of
applications trickier to handle, if not unsuitable for EPEL.

Back at the time, when I looked at packaging Grafana, it already
required what felt like 100 js dependecies, where some of them were
only used at build time (for copying, concatenating files etc).

Prometheus is already included in Fedora, in an old version. The package
maintainer will probably accept patches and help.
> I suppose this is also a test if a distribution like Fedora/Epel can still
> be used to deploy the kind of apps written in 2018, or if it's condemned to
> fade and be replaced by other approaches like containers.

I tend to disagree here. For building containers, and I'd do that
from packages.

Matthias

[Nicolas Mailhot]

Le 2018-08-29 20:59, Matthias Runge a écrit :
> On Wed, Aug 29, 2018 at 03:25:09PM +0200, Nicolas Mailhot wrote:
> > I already spent a few months of work working on the Go layer, writing
> > Golang-to-rpm plumbing, packaging guidelines, packaging and testing 
> > hundreds
> > of spec files. It is finally looking like something that could end up 
> > in the
> > distribution, even though there is still a ton of work to do 
> > plumbing-side
> > to make Go packaging in Fedora simple and convenient. And I'd like to 
> > spend
> > more time making this plumbing a reality.

Hi,
> thanks for sharing, this is awesome.

Thanks
> While I believe, EPEL is unsuitable for this kind of applications, we
> should have them in Fedora. For example prometheus is also packaged in 
> a
> recent version in Debian, while Grafana is still at version 2.6, which
> is fairly old.

This kind of "modern" application is certainly challenging due to its 
deep dependency graph and the churn in those deps, sure. EPEL 
as-it-exists-today is certainly unsuitable, but Fedora itself needs 
changes. If we can solve the problem Fedora-side, the I'm quite sure 
EPEL can change too.
> Back at the time, when I looked at packaging Grafana, it already
> required what felt like 100 js dependecies, where some of them were
> only used at build time (for copying, concatenating files etc).

Well that's an order or magnitude less than the Go layer so it's doable. 
But seriously, if the only blocker is to iterate some form of template 
packaging over a huge number of components, I can do it. I just need 
someone more familiar with javascript packaging in Fedora to point me to 
the correct template, a couple of concrete packaging examples, and how 
to compute the list of components to package.
> Prometheus is already included in Fedora, in an old version. The 
> package
> maintainer will probably accept patches and help.

This version is useless, it's not been done in unbundled mode, and the 
app itself has changed and improved radically since. The packaging needs 
to be redone cleanly from scratch. And I think I've done 90% of what is 
necessary Go side, I need help on the js front.

(the original packager was/is doing Go in Fedora, I've worked a lot with 
him those past months, I'm quite sure he wants even less to do with the 
javascript bits in prometheus than me)
> > I suppose this is also a test if a distribution like Fedora/Epel can 
> > still
> > be used to deploy the kind of apps written in 2018, or if it's 
> > condemned to
> > fade and be replaced by other approaches like containers.
>
> I tend to disagree here. For building containers, and I'd do that
> from packages.

I agree with you in theory. But if we can't manage to package actual 
complex apps like Prometheus or Grafana, that container people manage to 
do, that would tend to show our theory is wrong :(

Regards,

[Matthias Runge]

On Thu, Aug 30, 2018 at 11:36:06AM +0200, Nicolas Mailhot wrote:
> This version is useless, it's not been done in unbundled mode, and the app
> itself has changed and improved radically since. The packaging needs to be
> redone cleanly from scratch. And I think I've done 90% of what is necessary
> Go side, I need help on the js front.

I bet you already saw the javascript packaging guidelines

https://fedoraproject.org/wiki/Packaging:JavaScript

In some cases, I've seen the files just copied over, no "building".
> I agree with you in theory. But if we can't manage to package actual complex
> apps like Prometheus or Grafana, that container people manage to do, that
> would tend to show our theory is wrong :(

You mean, you don't want to build a container like this?

https://github.com/openstack/kolla/blob/master/docker/prometheus/prometheus-...

[Matthias Runge]

On Thu, Aug 30, 2018 at 11:36:06AM +0200, Nicolas Mailhot wrote:
> > thanks for sharing, this is awesome.
>
> I agree with you in theory. But if we can't manage to package actual complex
> apps like Prometheus or Grafana, that container people manage to do, that
> would tend to show our theory is wrong :(

While I can not promise to put a good chunk of work into this,
I'd love to see both Grafana and Prometheus (and probably alertmanager
and friends) as part of CentOS Opstools.
That may be a good starter, since they'd be the only golang packages there
(if you ignore skydive, which bundles all dependencies).

[Piotr Popieluch]

On Wed, Aug 29, 2018 at 3:25 PM Nicolas Mailhot 
wrote:
> Hi,
>
> I'm currently investigating the packaging of Prometheus and Grafana in
> Fedora/Epel.
>
> Grafana OTOH has a clean codebase with a build process that uses yarn to
> get third-party javascript
> https://github.com/grafana/grafana/blob/master/yarn.lock
>
> Therefore, I'm looking for help :
> either pointers or advice on how to package this javascript cleanly
>
> or
>    2. ideally, people willing to take over this javascript packaging, so
> I can focus on finishing the Golang plumbing in Fedora

I tried to package javascript packages for Grafana a couple years back but
found that by the time I got half of the packages done the project updated
some library and I would need to package 50 more dependencies. At some
point I just gave up, it is just too much work for too little benefit, I
just download the rpm from the Grafana website. Also maintaining those
packages turned out to take more time than I anticipated. An update to some
library often introduces many new dependencies which need to be packaged,
some modules depend on specific versions of libraries which makes things
even harder.

I was actually planning in orphaning many of the nodejs packages I
"maintain", I'll just keep them for now, many of them are needed for
Grafana. If you want to co-maintain them let me know.

Anyway, good luck

Piotr