>> -----Original Message-----
>> From: Andreas Ericsson [mailto:[email protected]]
>> Sent: Friday, June 05, 2009 5:31 AM
>> To: nagios-devel
>> Subject: [Nagios-devel] Short notes from Nagios devcon #1
>>
>
> [ ... good stuff ... ]
>
>> New GUI
>> -------
>> We'll likely use Ninja as the new default GUI for Nagios. Currently,
>> Ninja only supports fetching data from the Merlin database. If
>> anyone's interested in adding a filebased driver for Ninja, taking
>> this step would be a great deal easier. Contact me, this list or
>> Per Asberg ([email protected]) if you're a competent PHP programmer
>> and would like to help out. Sources and clone-url are available at
>> http://git.op5.org/git/nagios/ninja.git
>>
>> --
>> Andreas
>
>>From what I've seen of the conference online (thanks, OP5 for making
> this available!),
Yw.
> I'm wondering why Merlin isn't being talked about as
> an NDOutils replacement. Is this just too contentious of an issue? Or,
> unlike Ninja, is OP5 not willing to release control over it?
Merlin *is* an ndoutils replacement, and I marked it as such in my own
presentation (which should be available online from somewhere). When/if
Ninja is made the default GUI (around late august at the very earliest),
it will still depend on Merlin as a backend, so either Merlin will be
the default nagios-to-database layer, or Ninja will have to be adapted
to work with filebased data or with some other database layer such as
NDOUtils.
As for releasing control, that takes a bit of a longer explanation.
Per Asberg is the current Ninja maintainer. He decides what goes in and
what doesn't. Me and some other people also have push access to the ninja
repository, so I guess we're sort of co-maintaining it with Per.
Per will remain as the Ninja maintainer for the foreseeable future, just
as I will remain Merlin maintainer for quite some time yet, so in a sense
op5 aren't "releasing control" over those two projects. In a different
and far more *real* sense of the word, we've never really had control
over them in the first place. The repositories are available online. The
code is GPL. Anyone who doesn't like what we're doing is free to fork
the code and make their own modifications as much as they want. That's
what the GPL is really all about. We have control over the projects as
long as we continue to provide the most wanted features and the best
solutions to the problem. When we stop doing that, someone *will* fork
the code and good luck to them, says I.
Personally, I will maintain Merlin exactly as I think other projects
should be maintained. When prominent contributors appear and send some
valuable and good patches to me, I'll be quite willing to share write
access to the Merlin repository with those people. I have no doubts
Per will do the exact same thing with Ninja. The opensource world is
after all a meritocracy; Each and everyone is valued by what they make,
not who they are.
> From what
> I saw it seems like the direction to go, but maybe I missed something
> (haven't gone through all the conference yet).
>
I agree. Partially because of what I wrote in my own presentation about
linear scaling, but also because there seems to be a shortage of willing
maintainers for NDOUtils, and Ethan's too busy to manage two large-ish
opensource projects on his own. op5 really can't take over NDOUtils as we
need the clustering capabilities of Merlin and it'll be hard for us to
make management accept the cost of maintaining two competing projects.
Maybe Opsera can take over NDO, but I think most companies will wait and
see what becomes of the Nagios+Merlin+Ninja suite before spending any
resources on competing solutions. That leaves us with willing community
members. Any takers? Contact Ethan (or this list) if you are. It's his
project, so it's his call if he wants to hand it over (although it's
ofcourse always possible to fork it).
Note that these are just guesses. I obviously can't speak for Opsera,
Groundworks, Netways, the Nagios community, or even the op5 management
group. Perhaps the Icinga-fo
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]