Should prometheus be behind a build tag?

[kshlm]

We're trying to make use of mgmt in GlusterD-2.0 (or GD2). But the initial effort required to get mgmt vendored and built is lot.

This is mainly because lib package right now is basically the full mgmt, including all the resources, monitoring bits. I've had manually pin dependencies for mgmt resources, to prevent dependency clashes. The dependency on libvirt for the virt resource is causing failures in our CI.

The idea for using mgmt in GD2 is to use mgmt as the inbuilt orchestration engine. We will build and use custom GlusterFS resources with mgmt, to do our work. But pulling in lib pulls in stuff like prometheus, libvirt, augeas and other resources that we don't require.

Could lib be simplified and made leaner, to just be the core mgmt engine without any attached resources?

[purpleidea]

@kshlm I'll respond in a few parts...

1) Firstly some resources like augeas and libvirt can be easily disabled. See here in our documentation: https://github.com/purpleidea/mgmt/blob/master/docs/documentation.md#compilation-options

If there is a significant piece (and reason!) that you think it should have a build disable option, let us know and send a patch :)

2) I don't agree that mgmt needs to get "leaner" -- What is the actual problem you're trying to solve? The tool is already many times faster than Puppet and other tools, and the builds are much much smaller as well.

Leaner for no technical reason is a non issue as far as I'm concerned. If it was a "mgmt is X MB, and we need to run it on some device that only has Y size available, that would be a different question.

3) Since this is GlusterD related, I don't understand the problem with pulling in things is. mgmt doesn't pull in much actually. The biggest thing it pulls in is etcd (and the etcd deps) and those were wanted by glusterd anyways...

I think the biggest mistake glusterd2 is making is vendoring all the deps. This is IMO a death sentence because it's very hard to unvendor or move to newer versions. Instead run everything as close to git master as possible, that way if something breaks, you'll know right away, and it can be reported upstream, or patched in glusterd easily. Much easier than fighting with 10+ breaks all at once.

As a result, we only vendor things that are necessary because of upstreams. Eg: etcd is vendored (only the grpc libs though) because they like to break their git master! :( https://github.com/coreos/etcd#etcd :

Note: The master branch may be in an unstable or even broken state during development.

(from the etcd homepage)

And as an aside, we have git submodules so that the entire code base isn't copied in!!! https://github.com/purpleidea/mgmt/tree/master/vendor/ talk about bloat in some other projects!

HTH -- I will close this issue, but we can talk more about this in #mgmtconfig I think the thing you already want exists as mentioned in number 1. If prometheus is an issue and the prometheus maintainer agrees, we could consider disabling it with a build tag.

Cheers!

[roidelapluie]

@purpleidea once again you close an issue .... this starts to be disturbing.

[purpleidea]

@roidelapluie The solution described in number one is already available.

We don't collect issues, we collect patches... If there's something directly actionable that someone is working on we should know. If I've misunderstood something LMK.

[roidelapluie]

This not how open source work. Discussions are important too. There is a difference between closing issues without activity for a month and closing an issue after the first answer. The first one is okay, the second one means «shut up and patch». It is not the first time you do so, but in this case this is an important topic. The fact that you do not agree does not mean that everyone thinks like you.

[roidelapluie]

I agree with OP. Maybe we could move resources to their own packages ? That would allow you to use 3rd party resources as well. Not sure about how to make that technically possible however.

[purpleidea]

@roidelapluie Well there are two issues I see that can be discussed:

1) Do you think have prometheus as a noprometheus build tag is a good idea, and if so does someone want to write this patch?

2) Resources into their own packages is actually something I've already started hacking on. The idea would be to use the 1.8 plugin interface for them. That doesn't need tracking in an issue unless more than one person is working on it.

Reopening pending 1) ...

[purpleidea]

As an aside, I do strongly agree here:

Discussions are important too.

But on longer reflection, I recommend the mailing list. It's been quiet, and I think this is a good place for that sort of thing. It would be great if it's used more.

[roidelapluie]

I am a bit surprised that gluster2 does not offer a prometheus interface. Sounds like a missed opportunity. Is that in the roadmap? In that case this issue becomes less critical.

[kshlm]

Firstly some resources like augeas and libvirt can be easily disabled. See here in our documentation: https://github.com/purpleidea/mgmt/blob/master/docs/documentation.md#compilation-options

I know about GOTAGS, and I tried them. But the builds still fail on CI and I don't know why.

If that did work, I might not have made this request at all.

[purpleidea]

On Tue, Feb 28, 2017 at 2:57 AM, Kaushal M notifications@github.com wrote:

I know about GOTAGS, and I tried them https://github.com/gluster/glusterd2/pull/247/commits/e2d8fec4b2ce101ae5a58fb5783e0eab6ec507fa#diff-d99b26f864526f6f8f79861d49deb922R20. But the builds still fail on CI and I don't know why.

Got logs? AFAICT it's the vendoring which is tripping you up.

[roidelapluie]

You should use: go build -ldflags "${LDFLAGS}" -o $OUTDIR/$BIN -tags "novirt noaugeas"

GOTAGS env variable is transformed in our Makefile.