I would almost argue the easier way would be to munge the events if possible to not clear for the backup compressor - i.e. the backup should be a separate logical "interface" to the primary... Though this of course depends a LOT on how you're actually monitoring this stuff.
As for hacking the code, sorry, I'm not a Zenoss code guru. -- James Pulver Information Technology Area Supervisor LEPP Computer Group Cornell University nxumdon wrote, On 2/12/2009 4:11 PM: > No, it wasn't the outage that was resolved in a minute...but a compression > failure in a microwave cable...it sent the failure alarm, and then the backup > compressor kicked in, which cleared the alarm...this backup compressor ran > for far too long and as a result the entire shelter died...long political > story...sadly we do not have full control over this site and thus we're at > the mercy of the client for what sort of environmental monitoring they're > willing to install. > > Anyone have any ideas on how or where to start looking for hacking this to > run faster? Thanks. > > > > > -------------------- m2f -------------------- > > Read this topic online here: > http://forums.zenoss.com/viewtopic.php?p=31251#31251 > > -------------------- m2f -------------------- > > > > _______________________________________________ > zenoss-users mailing list > [email protected] > http://lists.zenoss.org/mailman/listinfo/zenoss-users _______________________________________________ zenoss-users mailing list [email protected] http://lists.zenoss.org/mailman/listinfo/zenoss-users
