Closed jryberg closed 10 years ago
We tried to fool the system by doing some fuggly work arounds like $statement =~ s/last_command_check/last_log_rotation/g; just to see what happened and we where able to connect a fresh install of op5 but later on during the collection of status from op5, op5 reported error 400 Table 'status has no column check_freshnes' to some GET commands via livestatus. Thinks this is why it will not work?
You can use https://github.com/sni/livestatus for now.
@sni, thanks. Did you just added last_command_check again?
Will consult op5 as well,
Thanks.
I only did these changes basically: https://github.com/sni/livestatus/commit/59f31eb59c5fa93e0447d716c0dad908cbbd4738
Hi,
I have been in contact with op5 and the developer that has been working with livestatus for Nagios 4/op5 and this data does not make any sense any more.
The patch "might" work, but there are no guaranties that it will work well with Nagios 4/op5.
The suggestion was instead to read the protocol version and only get the object that are needed for the operation by calling the tables per name and not try to get all data and parse it with name-to-type tricks.
I would love to give you a patch but I can't perl that well to be able to do this.
Thanks for your support and otherwise a great software.
Best regards Johan Ryberg
2013/11/13 Sven Nierlein notifications@github.com
I only did these changes basically: sni/livestatus@59f31ebhttps://github.com/sni/livestatus/commit/59f31eb59c5fa93e0447d716c0dad908cbbd4738
— Reply to this email directly or view it on GitHubhttps://github.com/sni/Thruk/issues/227#issuecomment-28402806 .
The problem is, i don't want to have different code for each livestatus implementation. I think the livestatus api should be compatible over all products and implementations. Using different querys for each implementation makes the Thruk code more complicated, less readable and maintainable for zero benefit. The op5 implementation is designed to work with nagios4 and ninja.
I understand that, very much indeed.
Will be the end of Thruk? More and more people are using Nagios 4 and in my communication with the developer it was clear that this is deprecated and will not return.
Best regards Johan Ryberg
2013/11/15 Sven Nierlein notifications@github.com
The problem is, i don't want to have different code for each livestatus implementation. I think the livestatus api should be compatible over all products and implementations. Using different querys for each implementation makes the Thruk code more complicated, less readable and maintainable for zero benefit. The op5 implementation is designed to work with nagios4 and ninja.
— Reply to this email directly or view it on GitHubhttps://github.com/sni/Thruk/issues/227#issuecomment-28565033 .
no, why should this be the end of thruk? there will be a solution somehow and until then, you just need to take my livestatus module instead of the op5 one.
i will close this issue. I don't care about Nagios 4 since the focus will be on naemon.
It would be great to have support of the new livestatus and other backend changes since nagios-core 3 that are not compatible with Thruk anymore.