Ubuntu
nagios-plugins package

Bug #1273484
Comment #79

Comment 79 for bug 1273484

Revision history for this message

In Red Hat Bugzilla #1054340, Scott (scott-redhat-bugs) wrote on 2014-01-24:

#79

(In reply to Sam Kottler from comment #75)
> (In reply to Mark Hill from comment #74)
> > (In reply to Sam Kottler from comment #69)
> > > (In reply to Mark Hill from comment #65)
> > > > This must be some kind of joke right? Are there serious considerations to
> > > > get rid of the nagios-plugins RPM? I thought it was a bad idea before, but
> > > > now after reading that last comment and associated blog article, I am
> > > > outraged! And are we really worried that the new team writing the code for
> > > > these plugins are not going to be up to par? REALLY? I'm pretty sure a
> > > > fifth-grader could meet the standards the previous team set, It isn't
> > > > excately a high bar to meet. I promise I am not tyring to be degrading, and
> > >
> > > "I'm pretty sure a fifth-grader could meet the standards the previous team
> > > set" but you're not trying to be degrading...
> > >
> >
> > Fair enough, that was a bit harsh, I let my emotions get the better of me
> > and I apologize.
> >
> > > Anyways, given I don't find your name in any of the SCM logs, email lists,
> > > or anything Nagios related (other than promoting Nagios XI on stack
> > > overflow) I'm not sure I trust your opinion on this.
> > >
> >
> > The sensitive nature of my work requires that I keep a low profile. (I even
> > had to receive clearance to post here) So although you don't see my name
> > publicly, several others who have commented here are familiar with my
> > extensive nagios work.
> >
> > > > I sincerely appreciate the work they did! I just think it is ridiculous to
> > > > assume that because of the changes that got everyone all upset we should
> > > > drop the nagios-plugins rpm and move to nagios-insertyourideahere-plugins.
> > > > As other "community members" have already said, I do not want to deal with
> > > > all of the dependency issues this creates, just because of a little pissing
> > > > match.
> > >
> > > It actually creates virtually no dependency issues AFAIK; can you elaborate?
> > >
> >
> > We have a massive nagios infrastructure built (and team dedicated to it). We
> > rely heavily on the nagios-plugins rpm. We have scripts all over the place
> > that use yum to install and update the plugins. And now by the sounds of it,
> > we are going to have to touch each one of these if we want the
> > nagios-plugins from the new team? Does that help clarify my concern?
>
> It does, thanks. That being said it's just updating a bunch of package
> names; there won't be any additional process. No paths will change if you
> stick with the nagios-core-plugins package.
>
> >
> > > >
> > > > Sam: I really appreciate you dealing with this, but please, keep a straight
> > > > head on this.
> >
> > Again, I really appreciate your work on this Sam. I don't have a stake in
> > this other than the time my team is going to have to spend fixing stuff if
> > you decide to force us to go to 'nagios-core-plugins'. And my biggest
> > concern is what if my team misses one? We are going to have mismatches
> > across our various networks, and anything we have built on top of that will
> > break. And yes, this would be easy to accomplish if are networks were not
> > completely isolated from one another. Several of our network require
> > out-of-band management, so again, I think you understand my concern. This
> > just seems like a very unnecessary headache in the making.
>
> Understood and I totally sympathize with you on that, but this wasn't really
> my decision. You can talk with Nagios Enterprises about how they're making
> the lives of their users more difficult - maybe they'll listen.

@Sam - How is it that you think Nagios Enterprises is making the lives of their users more difficult?

Nagios Enterprises wants the nagios-plugins package to continue to exist with the project that they own/maintain.

Nagios Enterprises wants the millions of installs of Nagios and it plugins to continue to use the same package names as always for the projects which they own, no matter who they appoint to the team.

Changing of the package name to not refer to the official Nagios Plugins, with the team the project owner put in place is what would be making the lives of the users more difficult.

A worst case scenario would be to have an install/upgrade of nagios-plugins automatically upgrade to a package created by the Monitoring Plugins team.

This would be akin to running Fedora on your machine and after running yum update, you find you have Linux Mint installed and no longer Fedora...

Would this be what you expected?

(In reply to Sam Kottler from comment #75)
> (In reply to Mark Hill from comment #74)
> > (In reply to Sam Kottler from comment #69)
> > > (In reply to Mark Hill from comment #65)
> > > > This must be some kind of joke right? Are there serious considerations to
> > > > get rid of the nagios-plugins RPM? I thought it was a bad idea before, but
> > > > now after reading that last comment and associated blog article, I am
> > > > outraged! And are we really worried that the new team writing the code for
> > > > these plugins are not going to be up to par? REALLY? I'm pretty sure a
> > > > fifth-grader could meet the standards the previous team set, It isn't
> > > > excately a high bar to meet. I promise I am not tyring to be degrading, and
> > > 
> > > "I'm pretty sure a fifth-grader could meet the standards the previous team
> > > set" but you're not trying to be degrading...
> > > 
> > 
> > Fair enough, that was a bit harsh, I let my emotions get the better of me
> > and I apologize.
> > 
> > > Anyways, given I don't find your name in any of the SCM logs, email lists,
> > > or anything Nagios related (other than promoting Nagios XI on stack
> > > overflow) I'm not sure I trust your opinion on this.
> > > 
> > 
> > The sensitive nature of my work requires that I keep a low profile. (I even
> > had to receive clearance to post here) So although you don't see my name
> > publicly, several others who have commented here are familiar with my
> > extensive nagios work. 
> > 
> > > > I sincerely appreciate the work they did! I just think it is ridiculous to
> > > > assume that because of the changes that got everyone all upset we should
> > > > drop the nagios-plugins rpm and move to nagios-insertyourideahere-plugins.
> > > > As other "community members" have already said, I do not want to deal with
> > > > all of the dependency issues this creates, just because of a little pissing
> > > > match. 
> > > 
> > > It actually creates virtually no dependency issues AFAIK; can you elaborate?
> > > 
> > 
> > We have a massive nagios infrastructure built (and team dedicated to it). We
> > rely heavily on the nagios-plugins rpm. We have scripts all over the place
> > that use yum to install and update the plugins. And now by the sounds of it,
> > we are going to have to touch each one of these if we want the
> > nagios-plugins from the new team? Does that help clarify my concern?
> 
> It does, thanks. That being said it's just updating a bunch of package
> names; there won't be any additional process. No paths will change if you
> stick with the nagios-core-plugins package.
> 
> > 
> > > > 
> > > > Sam: I really appreciate you dealing with this, but please, keep a straight
> > > > head on this.
> > 
> > Again, I really appreciate your work on this Sam. I don't have a stake in
> > this other than the time my team is going to have to spend fixing stuff if
> > you decide to force us to go to 'nagios-core-plugins'. And my biggest
> > concern is what if my team misses one? We are going to have mismatches
> > across our various networks, and anything we have built on top of that will
> > break. And yes, this would be easy to accomplish if are networks were not
> > completely isolated from one another. Several of our network require
> > out-of-band management, so again, I think you understand my concern. This
> > just seems like a very unnecessary headache in the making.
> 
> Understood and I totally sympathize with you on that, but this wasn't really
> my decision. You can talk with Nagios Enterprises about how they're making
> the lives of their users more difficult - maybe they'll listen.