Re: [Nagios-devel] Nagios is dead! Long live Icinga!
Posted: Fri May 08, 2009 6:19 am
Hendrik Baecker wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Andreas Ericsson schrieb:
>> Hendrik Baecker wrote:
>>> Andreas Ericsson schrieb:
>>> I hope so, I realy don't want to loose all my commits on icinga.
>> Ah, so you're using git already?
>>
> Yes, we are on git and I have to say I love it more from day to day. A
> SCM that really can handle branches and merges. Wonderfull and fits
> perfectly for bigger developer bases.
>
>>>> I hope Icinga forks from that DSCM, and uses the same DSCM to
>>>> maintain their own code so that a future merge becomes as painless
>>>> as possible.
>>> Icinga forked from a cvs2git copy, so future merging might be possible.
>>>
>> It would even be trivial if that cvs2git repository is available for
>> cloning
>>
> Call me insane, but I'm afraid to lose face with publishing a half ready
> code base, even if I know that I can lose it when you read my 1527
> commit messages *just kidding*.
>>> As I mentioned before. Code base will be opened in the next days as a
>>> pre-alpha, mega-super-testing phase
>>> No, it's not only a political stunt to get Ethan to wake up again.
>> mega-super-testing is fine, so long as it's code :p
>>
> Be patient with my face
>
>> Including object sizes and layout? If so, you're doing something good
>> and something bad at the same time.
>> There's room for improvement in the objects in Nagios today. A lot of
>> integer flags can (and should) be removed and reworked into bitmasks.
>> That would make matching them against their dependencies and contacts'
>> options trivial
>>
>> if (1 state & contact->notify_options & host->notification_options)
>> send_host_notification(host);
>>
> I know you are some kind of magician but primary goal is to be more open
> to be able to share the work on more shouldes.
Well, "magic" like the above is usually tucked away in a macro, but whatever.
>>> The next steps should be a open development of the blocking ndoutils
>>> and better db abstraction.
>> I know you've taken a look at merlin (though I don't know if you saw the
>> figures of the NDOUtils scalability testing we did). Any reason you chose
>> to move forward with NDOUtils? Or is the database schema chopped into a
>> more scalable form as well?
>>
> I am a huge amount of commits behind the actual version and I love your
> idea behind it.
> Correct me if I'm wrong but merlin wasn't designed as a better ndo2db,
> wasn't it?
No, that's true. It was designed as an event-transport mechanism. However,
it's really trivial to add support for *doing* something with the events
while they're in transit, so it made sense to add database support to it.
The way I see it, this makes perfect sense from a unix standpoint, since
* it keeps each component small and to the point
* each component can be ripped out and replaced with something else
* small components can easily be chained together, and the result is almost
always that the total ends up being bigger than the sum of its pieces
> Up to know it looks more like a benefit for monitoring
> performance improvements like DNX (in the scope of delegate the checking
> work), in this thoughts I don't understand why I should have to use
> merlin to fill a database?
Well, take a look at what NDOUtils does.
1. An event is generated in Nagios.
2. The NDO module takes that event and sends it to the NDO daemon.
3. The NDO daemon picks up the event, parses it and inserts it into
the database.
Now look at what merlin does.
1. An event is generated in Nagios.
2. The merlin module sends the event to the merlin daemon.
3. The merlin daemon sends the event to other merlin daemons.
4. The merlin daemon in the other end sends the event to a merlin module,
which updates status inside Nagios accordingly.
Now, if you add database capabilities to this chain of events, you'll see
two very interesting things becoming possible.
The first is that we no longer need to use a separate module to insert
stuff into the database.
The second is that events will transparently filter up to several instances
of GUI dat
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Andreas Ericsson schrieb:
>> Hendrik Baecker wrote:
>>> Andreas Ericsson schrieb:
>>> I hope so, I realy don't want to loose all my commits on icinga.
>> Ah, so you're using git already?
>>
> Yes, we are on git and I have to say I love it more from day to day. A
> SCM that really can handle branches and merges. Wonderfull and fits
> perfectly for bigger developer bases.
>
>>>> I hope Icinga forks from that DSCM, and uses the same DSCM to
>>>> maintain their own code so that a future merge becomes as painless
>>>> as possible.
>>> Icinga forked from a cvs2git copy, so future merging might be possible.
>>>
>> It would even be trivial if that cvs2git repository is available for
>> cloning
>>
> Call me insane, but I'm afraid to lose face with publishing a half ready
> code base, even if I know that I can lose it when you read my 1527
> commit messages *just kidding*.
>>> As I mentioned before. Code base will be opened in the next days as a
>>> pre-alpha, mega-super-testing phase
>>> No, it's not only a political stunt to get Ethan to wake up again.
>> mega-super-testing is fine, so long as it's code :p
>>
> Be patient with my face
>
>> Including object sizes and layout? If so, you're doing something good
>> and something bad at the same time.
>> There's room for improvement in the objects in Nagios today. A lot of
>> integer flags can (and should) be removed and reworked into bitmasks.
>> That would make matching them against their dependencies and contacts'
>> options trivial
>>
>> if (1 state & contact->notify_options & host->notification_options)
>> send_host_notification(host);
>>
> I know you are some kind of magician but primary goal is to be more open
> to be able to share the work on more shouldes.
Well, "magic" like the above is usually tucked away in a macro, but whatever.
>>> The next steps should be a open development of the blocking ndoutils
>>> and better db abstraction.
>> I know you've taken a look at merlin (though I don't know if you saw the
>> figures of the NDOUtils scalability testing we did). Any reason you chose
>> to move forward with NDOUtils? Or is the database schema chopped into a
>> more scalable form as well?
>>
> I am a huge amount of commits behind the actual version and I love your
> idea behind it.
> Correct me if I'm wrong but merlin wasn't designed as a better ndo2db,
> wasn't it?
No, that's true. It was designed as an event-transport mechanism. However,
it's really trivial to add support for *doing* something with the events
while they're in transit, so it made sense to add database support to it.
The way I see it, this makes perfect sense from a unix standpoint, since
* it keeps each component small and to the point
* each component can be ripped out and replaced with something else
* small components can easily be chained together, and the result is almost
always that the total ends up being bigger than the sum of its pieces
> Up to know it looks more like a benefit for monitoring
> performance improvements like DNX (in the scope of delegate the checking
> work), in this thoughts I don't understand why I should have to use
> merlin to fill a database?
Well, take a look at what NDOUtils does.
1. An event is generated in Nagios.
2. The NDO module takes that event and sends it to the NDO daemon.
3. The NDO daemon picks up the event, parses it and inserts it into
the database.
Now look at what merlin does.
1. An event is generated in Nagios.
2. The merlin module sends the event to the merlin daemon.
3. The merlin daemon sends the event to other merlin daemons.
4. The merlin daemon in the other end sends the event to a merlin module,
which updates status inside Nagios accordingly.
Now, if you add database capabilities to this chain of events, you'll see
two very interesting things becoming possible.
The first is that we no longer need to use a separate module to insert
stuff into the database.
The second is that events will transparently filter up to several instances
of GUI dat
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]