Managing a compatibility layer for this feature and 2.4 won't be easy, and will lead to some buggy things.
On Tue, Jul 17, 2012 at 9:35 AM, Ludovic Gasc <email@example.com>
On Sat, Jul 14, 2012 at 8:22 PM, Denis GERMAIN <firstname.lastname@example.org>
If people have to migrate their production server in RHEL 5 to RHEL 6 to get basic Shinken working, I feel that this is somewhat less true : in my last job, I proposed Shinken as an alternative and I had to get python26 along with native python 2.4 of the production RHEL 5.4. This is not impossible to do, but neither is it trivial. I don't know if I am an exception, but I have a lot of RHEL 5 running and I still need a few RHEL 4 for some dusty software that no one knows how to upgrade.
From my point of view, if you want to test shinken, you setup a new VM with RHEL or CentOS 6, you won't install on the same server of Nagios to test.
If Shinken can work more or less out-of-box with the latest stable version of the major distributions on the production servers (aka Debian and RHEL/CentOS), it's enough.
it's good to see an animated thread :)
It's a hard point indeed. The 2.4 is starting to be a problem in some part of the code. Of course some part of code are already unavailable for 2.4 users (and when we talk about 2.4, we are in fact talking about RH5 users that don't have the additional repository for python2.6).
If we put aside the python2.4/2.5 age (running an unmaintained app is an admin choice), the main problem in the 2.4 lock came with Pyro. I would like to switch connections from synchronous to asynchronous mode, but this is only available in 4 versions (and not the first ones if I'm not wrong). With a large number of satellites, this can be a huge gain with timeout satellites (wait time = (Timeout) versus wait time = (N*Timeout)) and especially the boot time for large setups. But Pyro4 for this is >= 2.6.