Proposal: Deprecate prometheus/nagios-plugins in lieu of a 3rd party fork

[Bjoern Rabenstein]

Hi Prometheans,

If you are not interested at all in integrating Nagios with
Prometheus, you can stop reading now.

Otherwise, you are probably aware of the little plugin I maintain in
the https://github.com/prometheus/nagios_plugins repository. (The
plural is a lie, I guess when the repo was created by Joshua Hoffman
back in 2013, we had bolder plans with the integration than just one
measly shell script.)

Having an own repo in the prometheus GH org kind of suggests that
the Nagios integration is important and 1st class. Which is simply not
true. If we didn't have that repo today, we would certainly encourage
such an integrations to be maintained in a 3rd party repository, like
the hundreds of other integrations. The reason why the repo exists in
the prometheus GH org is purely historical (i.e. SoundCloud needed the
integration back then in 2013, and with essentially no other users
than SoundCloud itself, it was just natural to put it into the
prometheus GH org).

On top of that, I am not using Nagios anymore. One of my
accomplishments at SoundCloud was to remove Nagios/Icinga from the
tech stack. And Grafana Labs, my current employer, doesn't use
Nagios/Icinga either.

For the time being, I have been happy to keep maintaining the
prometheus/nagios_plugins repo, including reviewing the occasional bug
fix or minor improvement contributed to the project. However,
inevitably more involved feature requests or even contributions will
happen, and I don't feel qualified to review those. One of them can be
seen here: https://github.com/prometheus/nagios_plugins/issues/25
(The discussion on that issue is what lead to this mail of mine.)

I can see two options to go from here:

1. We find somebody that is qualified to maintain
prometheus/nagios_plugins in place.

2. We deprecate prometheus/nagios_plugins and refer to a 3rd party
integration (possibly based on forking prometheus/nagios_plugins) that
is properly maintained and developed. In this case, I'd keep the
existing repo around until further notice, but not accepting any
contributions besides important bug fixes.

Emil 'Skeen' Madsen, @Skeen on GH, filed above mentioned issue #25,
and he is already playing around with a feature-enriched fork. I would
now like to encourage Nagios/Icinga users to try out his fork, to be
found under https://github.com/magenta-aps/check_prometheus_metric and
give Emil feedback. If that turns out well, I suggest to go for
option (2), deprecate prometheus/nagios_plugins in lieu of
agenta-aps/check_prometheus_metric and list the latter as an
integration on https://prometheus.io

Please let me know what you think.
--
Björn Rabenstein
[PGP-ID] 0x851C3DA17D748D03
[email] bjo...@rabenste.in

[Brian Brazil]

This sounds reasonable to me. At some point we would kick it over to junkyard.

 

--

Brian Brazil

www.robustperception.io

[Ben Kochie]

I would prefer to start with an offer to give someone else access to maintain the code, rather than shutdown an existing codebase.

If this fork is better, maybe we can get them to merge everything and they take over?

Another option, we move it to prometheus-community.

--
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 prometheus-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200226160040.GJ27526%40jahnn.

[Julien Pivotto]

On 26 Feb 17:00, Bjoern Rabenstein wrote:
> Hi Prometheans,
>
> If you are not interested at all in integrating Nagios with
> Prometheus, you can stop reading now.
>

> 1. We find somebody that is qualified to maintain
> prometheus/nagios_plugins in place.

I think we can offer @Skeen to maintain the repo in
prometheus-community, if they are interested.

Before moving to community, it looks like
https://github.com/magenta-aps/check_prometheus_metric is not following
our guidelines regarding logos as the prometheus logo orange+black does
not exist.

> 2. We deprecate prometheus/nagios_plugins and refer to a 3rd party
> integration (possibly based on forking prometheus/nagios_plugins) that
> is properly maintained and developed. In this case, I'd keep the
> existing repo around until further notice, but not accepting any
> contributions besides important bug fixes.

Our doc says that in that case it should be moved to junkyard
https://prometheus.io/governance/#how-do-i-archive-or-remove-a-project

> Emil 'Skeen' Madsen, @Skeen on GH, filed above mentioned issue #25,
> and he is already playing around with a feature-enriched fork. I would
> now like to encourage Nagios/Icinga users to try out his fork, to be
> found under https://github.com/magenta-aps/check_prometheus_metric and
> give Emil feedback. If that turns out well, I suggest to go for
> option (2), deprecate prometheus/nagios_plugins in lieu of
> agenta-aps/check_prometheus_metric and list the latter as an
> integration on https://prometheus.io

I would prefer to have it moved to community, maybe moved+renamed
check_prometheus_metric, and be the original (push the fork into it)?

>
> Please let me know what you think.
> --
> Björn Rabenstein
> [PGP-ID] 0x851C3DA17D748D03
> [email] bjo...@rabenste.in
>

> --
> 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 prometheus-devel...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200226160040.GJ27526%40jahnn.

--
(o- Julien Pivotto
//\ Open-Source Consultant
V_/_ Inuits - https://www.inuits.eu

[Bjoern Rabenstein]

On 26.02.20 18:32, Ben Kochie wrote:
> I would prefer to start with an offer to give someone else access to maintain
> the code, rather than shutdown an existing codebase.

That would correspond to option (1) of what I suggested. However,
"rather than shutdown an existing codebase" suggests a false
dichotomy. My suggested option (2) would not involve shutting down the
existing codebase, at least not anytime soon.

For reference, here are my two suggested options:

1. We find somebody that is qualified to maintain
prometheus/nagios_plugins in place.

2. We deprecate prometheus/nagios_plugins and refer to a 3rd party
integration (possibly based on forking prometheus/nagios_plugins) that
is properly maintained and developed. In this case, I'd keep the
existing repo around until further notice, but not accepting any
contributions besides important bug fixes.

> If this fork is better, maybe we can get them to merge everything and they take
> over?

That might work. It would be good to get more opinions about this. I
sensed some reluctance in the past of having many "mere" maintainers
in the Prometheus GitHub org, without any intention to graduate to a
full prometheus-team member.

In this particular case, there is the additional concern that the
nagios-plugins repository would naturally live outside of the
Prometheus GitHub org. As said, it's only in there for historical
reasons.

Having said that, I'd be fine with keeping it there and recruit a
maintainer in place. But I'd like to have some confidence that we are
collectively OK with it.

> Another option, we move it to prometheus-community.

Yes, definitely. But again, it would be good to see more opinions
about this. (Personally, I'm not a great fan of
prometheus-community. I think the Prometheus GitHub org should contain
core components of the ecosystem, and the "community" consists of all
the hundreds of other repos that have to do with Prometheus. I don't
quite understand why we need a hybrid in between. But that's just my
personal opinion. I would not be opposed to having the "new" Nagios
plugin in prometheus-community, if that's what everybody else wants
and in particular if the future maintainer is also fine with it)

[Julien Pivotto]

On 02 Mar 14:06, Bjoern Rabenstein wrote:
> On 26.02.20 18:32, Ben Kochie wrote:
> > I would prefer to start with an offer to give someone else access to maintain
> > the code, rather than shutdown an existing codebase.
>
> That would correspond to option (1) of what I suggested. However,
> "rather than shutdown an existing codebase" suggests a false
> dichotomy. My suggested option (2) would not involve shutting down the
> existing codebase, at least not anytime soon.
>
> For reference, here are my two suggested options:
>
> 1. We find somebody that is qualified to maintain
> prometheus/nagios_plugins in place.
>
> 2. We deprecate prometheus/nagios_plugins and refer to a 3rd party
> integration (possibly based on forking prometheus/nagios_plugins) that
> is properly maintained and developed. In this case, I'd keep the
> existing repo around until further notice, but not accepting any
> contributions besides important bug fixes.
>
> > If this fork is better, maybe we can get them to merge everything and they take
> > over?

This fork has only started on January 13th, which is
pretty new.

> That might work. It would be good to get more opinions about this. I
> sensed some reluctance in the past of having many "mere" maintainers
> in the Prometheus GitHub org, without any intention to graduate to a
> full prometheus-team member.
>
> In this particular case, there is the additional concern that the
> nagios-plugins repository would naturally live outside of the
> Prometheus GitHub org. As said, it's only in there for historical
> reasons.
>
> Having said that, I'd be fine with keeping it there and recruit a
> maintainer in place. But I'd like to have some confidence that we are
> collectively OK with it.
>
> > Another option, we move it to prometheus-community.
>
> Yes, definitely. But again, it would be good to see more opinions
> about this. (Personally, I'm not a great fan of
> prometheus-community. I think the Prometheus GitHub org should contain
> core components of the ecosystem, and the "community" consists of all
> the hundreds of other repos that have to do with Prometheus. I don't
> quite understand why we need a hybrid in between. But that's just my
> personal opinion. I would not be opposed to having the "new" Nagios
> plugin in prometheus-community, if that's what everybody else wants
> and in particular if the future maintainer is also fine with it)

I don't see how a plugin for another monitoring solution is a core
component. This requires expertise of Icinga/Nagios, so that would even
be better transfered to the Icinga community.

I will try to get Icinga community's feedback on this as well.

>
> --
> Björn Rabenstein
> [PGP-ID] 0x851C3DA17D748D03
> [email] bjo...@rabenste.in
>

> --
> 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 prometheus-devel...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200302130638.GF27526%40jahnn.

[Bjoern Rabenstein]

On 26.02.20 21:51, Julien Pivotto wrote:
>
> I think we can offer @Skeen to maintain the repo in
> prometheus-community, if they are interested.

OK, I'll take that as another vote for prometheus-community.

> Before moving to community, it looks like
> https://github.com/magenta-aps/check_prometheus_metric is not following
> our guidelines regarding logos as the prometheus logo orange+black does
> not exist.

It's not so much "our" guidelines as the LF trademark guidelines.

I honestly don't think this is a good time to start to be anal about
it. If we _actually_ want to follow the LF trademark guidelines
strictly, we should start with ourselves. The logo animations in the
PromCon videos are certainly more invasive that simple background
color changes. Personally, I have changed backgroud colors a lot for
slides etc. (One might argue, the white parts in the logo are actually
not white but transparent, anyway.) The PGW deliberately uses a
color-inverted version of the logo as a favicon.

> > 2. We deprecate prometheus/nagios_plugins and refer to a 3rd party
> > integration (possibly based on forking prometheus/nagios_plugins) that
> > is properly maintained and developed. In this case, I'd keep the
> > existing repo around until further notice, but not accepting any
> > contributions besides important bug fixes.
>
> Our doc says that in that case it should be moved to junkyard
> https://prometheus.io/governance/#how-do-i-archive-or-remove-a-project

That's not what the doc says. It only describes how to archive or
remove a project. I don't want to archive or remove the old repo, at
least not for a very generously measured transition period. I expect a
_lot_ of people using this simple script for some legacy Nagios
integration, and they are perfectly happy with the current state. I
don't want to break them as long as it doesn't cause us any effort to
keep things around. The situation would be different if the existing
repo would be a complex piece of software.

> > Emil 'Skeen' Madsen, @Skeen on GH, filed above mentioned issue #25,
> > and he is already playing around with a feature-enriched fork. I would
> > now like to encourage Nagios/Icinga users to try out his fork, to be
> > found under https://github.com/magenta-aps/check_prometheus_metric and
> > give Emil feedback. If that turns out well, I suggest to go for
> > option (2), deprecate prometheus/nagios_plugins in lieu of
> > agenta-aps/check_prometheus_metric and list the latter as an
> > integration on https://prometheus.io
>
> I would prefer to have it moved to community, maybe moved+renamed
> check_prometheus_metric, and be the original (push the fork into it)?

As far as I understood Emil, he aims for backwards
compatibility. However, the changes are invasive. There is very little
code left from the original script, if any at all. It is formally a
fork of the old repo, but for the reasons stated above, I would like
to keep the original repo around in place for a while (or,
alternatively, make Emil the maintainer of the original repo, see
original mail).

[Emil Madsen]

Hi, @Skeen here.

My original goal for the PR, and the following fork was indeed backwards

compatibility. I created the PR with the goal of merging our in-house nagios

plugin with the Prometheus one, as I though the resources spent on

maintaining it, might as well be shared, and benefit multiple people.

No reason to reinvent and remaintain the development of the wheel.

I don't have a lot of input with regards to the status of the current repository,

and whether it belongs in the Prometheus github organization, although it

does seem a bit like a misfit.

What I have a bit of input about, is my role as a potential future maintainer.

The way I see it, I was gonna have to maintain this script in-house anyway,

so the maintenance burden is one I already have. I do not feel strongly

about whether it'll be maintained in the promtheus github organization, in

the prometheus community, or where it already is.

[Bjoern Rabenstein]

On 02.03.20 06:55, Emil Madsen wrote:
>
> My original goal for the PR, and the following fork was indeed backwards
> compatibility. I created the PR with the goal of merging our in-house nagios
> plugin with the Prometheus one, as I though the resources spent on
> maintaining it, might as well be shared, and benefit multiple people.
>
> No reason to reinvent and remaintain the development of the wheel.
>
> I don't have a lot of input with regards to the status of the current
> repository,
> and whether it belongs in the Prometheus github organization, although it
> does seem a bit like a misfit.
>
> What I have a bit of input about, is my role as a potential future maintainer.
> The way I see it, I was gonna have to maintain this script in-house anyway,
> so the maintenance burden is one I already have. I do not feel strongly
> about whether it'll be maintained in the promtheus github organization, in
> the prometheus community, or where it already is.

Great. Thanks, Emil.

Which opens up three possibilities:

1. Make Emil the maintainer of the current prometheus/nagios_plugins
repository, where he can then merge in his current work in a way
that doesn't break backwards compatibility.

2. Create a Nagios plugin repo in prometheus-community and make Emil
the maintainer of it.

3. Leave Emil's fork where it is now and point to it from
prometheus/nagios_plugins and from prometheus.io

Option 2 and 3 come with the additional decision for how long we want
to keep the old prometheus/nagios_plugins repo around. That's also the
only thing I feel strongly about: Let's not remove the existing repo
anytime soon. I suspect there are a lot of silent users of it,
including usage patterns like downloading the script directly from GH
upon provisioning of a machine and such. (I guess GH move redirection
can help here, but then we really should be 100% backwards compatible,
which is planned anyway, but might turn out to be a burden.)

The feedback so far seems to gravitate towards option 2. But my
expectation is that that's the option with the most friction. Either
1 or 3 seems to create less changes. (But I'm also biased because I'm
generally happy to have maintainers in the Prometheus GH org that are
not (yet) team members, and I am not a huge fan of
prometheus-community in general).

Now that we have Emil's statement of commitment, could each of you who
has an opinion about it let me know what you think (again)? I will
leave this open for a couple of days and then implement the solution
that receives the best vibes. (If you feel strongly about any of the
solutions and you want to veto anything, it would also be a good time
to let me know.)

Cheers everyone.

[Brian Brazil]

I'd tend towards 3, we can have github auto-redirect. In any case it's easy to repoint things on the exporters page.

 

--

Brian Brazil

www.robustperception.io

[Bjoern Rabenstein]

Hello everyone,

Two weeks later, I'd like to wrap things up here.
Thanks for all your input.

On 04.03.20 19:45, Bjoern Rabenstein wrote:
>
> 1. Make Emil the maintainer of the current prometheus/nagios_plugins
> repository, where he can then merge in his current work in a way
> that doesn't break backwards compatibility.
>
> 2. Create a Nagios plugin repo in prometheus-community and make Emil
> the maintainer of it.
>
> 3. Leave Emil's fork where it is now and point to it from
> prometheus/nagios_plugins and from prometheus.io

These had been the three options on the table. From the feedback I
got, there is no clearly favored option, but on the other hand, nobody
seemed to feel very strongly either.

Therefore, let's go with the option of least change and least
friction, which is option (3). (At least in my opinion, but I'm also
the maintainer of the repo in question, so it's probably OK if I serve
as a tie breaker. :o)

That's my ingenious two-stage plan:

1. Emil, once you feel that your plugin is ready for production usage,
let me know and we'll add a deprecation notice to
prometheus/nagios_plugins and link your repo from the integrations
list on https://prometheus.io .

2. Once Emil's plugin has run for a while in the wild without
problems, we'll set up a GitHub redirect. (Implementation detail:
AFAICS, you cannot redirect to a repository that already exist. I
guess we have to hack that by deleting Emil's repo, transfering
prometheus/nagios_plugin to him, and then let him replay his
commits on top if it. Or something like that. We'll find a way.)
Optionally, if the redirect isn't feasible or Emil's plugin works
slightly differently after all, we'll keep around
prometheus/nagios_plugin for a while longer to then archive and
ultimately junkyard it (with ample of migration warning).

That's all. Emil, I'll wait for you to tell me your plugin is
production-ready.

[Emil Madsen]

Hello,

Sorry for the delay in responding,

A lot has been going on including vacation, moving and the pandemic.

I'm going to reply inline below.

onsdag den 18. marts 2020 kl. 18.04.16 UTC+1 skrev Björn Rabenstein:

Hello everyone,

Two weeks later, I'd like to wrap things up here.
Thanks for all your input.

On 04.03.20 19:45, Bjoern Rabenstein wrote:
>
> 1. Make Emil the maintainer of the current prometheus/nagios_plugins
>    repository, where he can then merge in his current work in a way
>    that doesn't break backwards compatibility.
>
> 2. Create a Nagios plugin repo in prometheus-community and make Emil
>    the maintainer of it.
>
> 3. Leave Emil's fork where it is now and point to it from
>    prometheus/nagios_plugins and from prometheus.io

These had been the three options on the table. From the feedback I
got, there is no clearly favored option, but on the other hand, nobody
seemed to feel very strongly either.

Therefore, let's go with the option of least change and least
friction, which is option (3). (At least in my opinion, but I'm also
the maintainer of the repo in question, so it's probably OK if I serve
as a tie breaker. :o)

That's my ingenious two-stage plan:

1. Emil, once you feel that your plugin is ready for production usage,
   let me know and we'll add a deprecation notice to
   prometheus/nagios_plugins and link your repo from the integrations
   list on https://prometheus.io .

We are currently running it in production at Magenta ApS, so I am up for it,

assuming you feel ok with it.

Whatever issues may arise we'll deal with as they arise.

 

2. Once Emil's plugin has run for a while in the wild without
   problems, we'll set up a GitHub redirect. (Implementation detail:
   AFAICS, you cannot redirect to a repository that already exist. I
   guess we have to hack that by deleting Emil's repo, transfering
   prometheus/nagios_plugin to him, and then let him replay his
   commits on top if it. Or something like that. We'll find a way.)
   Optionally, if the redirect isn't feasible or Emil's plugin works
   slightly differently after all, we'll keep around
   prometheus/nagios_plugin for a while longer to then archive and
   ultimately junkyard it (with ample of migration warning).

This sounds good to me, I'll let you have the call for when you think this is appropriate.

[Bjoern Rabenstein]

On 21.04.20 06:50, Emil Madsen wrote:
>
> onsdag den 18. marts 2020 kl. 18.04.16 UTC+1 skrev Björn Rabenstein:
>
> 1. Emil, once you feel that your plugin is ready for production usage,
>    let me know and we'll add a deprecation notice to
>    prometheus/nagios_plugins and link your repo from the integrations
>    list on https://prometheus.io .
>
> We are currently running it in production at Magenta ApS, so I am up for it,
> assuming you feel ok with it.
>
> Whatever issues may arise we'll deal with as they arise.

I have created https://github.com/prometheus/nagios_plugins/pull/26 .

Please review.

>
> 2. Once Emil's plugin has run for a while in the wild without
>    problems, we'll set up a GitHub redirect. (Implementation detail:
>    AFAICS, you cannot redirect to a repository that already exist. I
>    guess we have to hack that by deleting Emil's repo, transfering
>    prometheus/nagios_plugin to him, and then let him replay his
>    commits on top if it. Or something like that. We'll find a way.)
>    Optionally, if the redirect isn't feasible or Emil's plugin works
>    slightly differently after all, we'll keep around
>    prometheus/nagios_plugin for a while longer to then archive and
>    ultimately junkyard it (with ample of migration warning).
>
> This sounds good to me, I'll let you have the call for when you think this is
> appropriate.

I'll also announce the change on prometheus-announce, and then you'll
hopefully get some traffic, resulting in feedback should people hit
any issues.