Re: [prometheus-developers] Proposal: Deprecate prometheus/nagios-plugins in lieu of a 3rd party fork
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. -- 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-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200422134041.GX2315%40jahnn.
Re: [prometheus-developers] Proposal: Deprecate prometheus/nagios-plugins in lieu of a 3rd party fork
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. > That's all. Emil, I'll wait for you to tell me your plugin is > production-ready. > > -- > 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-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/b4e6c30d-019b-4fcc-acdb-ef90797717a0%40googlegroups.com.
Re: [prometheus-developers] Proposal: Deprecate prometheus/nagios-plugins in lieu of a 3rd party fork
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. -- 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-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200318170412.GH14683%40jahnn.
Re: [prometheus-developers] Proposal: Deprecate prometheus/nagios-plugins in lieu of a 3rd party fork
On Wed, 4 Mar 2020 at 18:45, Bjoern Rabenstein wrote: > 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.) > 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 -- 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-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAHJKeLrhyej1OJ%2BKKkmkPact77LUgtbO60uLp4%2BOaZ3ydyhtFQ%40mail.gmail.com.
Re: [prometheus-developers] Proposal: Deprecate prometheus/nagios-plugins in lieu of a 3rd party fork
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. -- 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-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200304184523.GQ14683%40jahnn.
Re: [prometheus-developers] Proposal: Deprecate prometheus/nagios-plugins in lieu of a 3rd party fork
mandag den 2. marts 2020 kl. 14.18.35 UTC+1 skrev Björn 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). > 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. > -- > 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-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/5855ca15-639b-4754-be16-4a27e2b07fcc%40googlegroups.com.
Re: [prometheus-developers] Proposal: Deprecate prometheus/nagios-plugins in lieu of a 3rd party fork
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). -- 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-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200302131833.GG27526%40jahnn.
Re: [prometheus-developers] Proposal: Deprecate prometheus/nagios-plugins in lieu of a 3rd party fork
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-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/prometheus-developers/20200302130638.GF27526%40jahnn. -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu -- 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-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200302131217.GA31438%40oxygen. signature.asc Description: PGP signature
Re: [prometheus-developers] Proposal: Deprecate prometheus/nagios-plugins in lieu of a 3rd party fork
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) -- 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-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200302130638.GF27526%40jahnn.
Re: [prometheus-developers] Proposal: Deprecate prometheus/nagios-plugins in lieu of a 3rd party fork
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-developers+unsubscr...@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 -- 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-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200226205148.GA7935%40oxygen. signature.asc Description: PGP signature
Re: [prometheus-developers] Proposal: Deprecate prometheus/nagios-plugins in lieu of a 3rd party fork
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. On Wed, Feb 26, 2020 at 5:00 PM Bjoern Rabenstein wrote: > 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 > > -- > 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-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/prometheus-developers/20200226160040.GJ27526%40jahnn > . > -- 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-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CABbyFmrdYyk3X27EV9NpV5woZ30hODuzDX5ZzknA%2B3ngQZMNAQ%40mail.gmail.com.
Re: [prometheus-developers] Proposal: Deprecate prometheus/nagios-plugins in lieu of a 3rd party fork
On Wed, 26 Feb 2020 at 16:00, Bjoern Rabenstein wrote: > 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. > This sounds reasonable to me. At some point we would kick it over to junkyard. -- Brian Brazil www.robustperception.io -- 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-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAHJKeLodxL9K0hE7ASPpvTwYQagUBWb7V-5c1e_4e%2BQc%3Dsiukw%40mail.gmail.com.
[prometheus-developers] Proposal: Deprecate prometheus/nagios-plugins in lieu of a 3rd party fork
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 -- 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-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200226160040.GJ27526%40jahnn.
