I completely left out a couple of interesting data points around this problem.
1. I originally noticed the error in zenhub.log after moving the 'Ghost' class from one Device class to another. No biggie; in both before and after cases, they were still contained under /Server/Linux. 2. After I'd deleted the offending class and subordinate classes (as well as the devices contained therein), I restarted Zenoss. When I checked zenhub.log and scrolled to the end, there were no new KeyError messages. 3. After I'd created new classes within /Server/Linux and recreated the devices (from scratch, by hand, through the web UI), I restarted Zenoss again. The KeyError messages had returned to zenhub.log. The only other relevant things I can think about at this time are: - the hostnames I recreated are identical to the hostnames which were contained subordinate to the problem 'Ghost' class. - there were events on those hostnames at one point in the past; just a wild guess, but maybe, even though I saved them to History, there's still some logic which reaches out to those hostnames, pulls back every record and attempts to traverse them, so maybe if I can find those records and delete them... I'll see if I can figure out how to purge those history records. -------------------- m2f -------------------- Read this topic online here: http://community.zenoss.com/forums/viewtopic.php?p=16436#16436 -------------------- m2f -------------------- _______________________________________________ zenoss-users mailing list [email protected] http://lists.zenoss.org/mailman/listinfo/zenoss-users
