I'd alreay enabled debugging. though rather than running lots of stuff in the
forground, I went for all the marbles and added a -v 10 in zenfunctions
start(). Sure that's overkill, but given that I was stopping and starting
zenoss with clean logs, it kind of worked.
I didn't see any errors in the logs. I did see references in the zenhub.log
about deleteing the devices. I ended up adding some logging to ApplyDataMap,
mostly in _updateRelationship(). I think I see the problem. Though this ought
to happen to anyone on the same code base. (for the record the is 2.2, which I
mentioned above, but its also the Ubuntu/Debian apt-get install of
zenoss-stack, which I don't think I said alreay).
Here's what I'm seeing
- HRSWRunMap.process builds an ObjectMap for each process, which it returns in
a RelationshipMap
- that relmap gets passed with the device into applyDataMap
- eventually we end up down in _updateRelationship()
- the relmap passed in is the one HRSWRunMap created
- relids (line 158) holds the ids of all the currently existing
processes in the map
- the block from line 160-183 sorts out the list. Theoretically
it ought to be removing existing objects on line 173, but it dosen't
- when we get to the loop at line 185-201, all the existing processes
in the model are still in relids, so they get deleted if not locked
The reason they get deleted is they don't have an id attribute to match aginst
so they fail the test on line 162. 2.2.0 is using revision 8156 of
HRSWRunMap.py. Most snmp collectors map an id is the table, but the id for an
os process is more complicated. However, that code isn't setting id anywhere
else. With no id, the ObjectMaps can't match anything in the model. By
contrast, if i go back to 2.1.3 where I'm not seeing this problem, there is a
block of code (lines 65-78) that sets the id to match what OSProcess.__init__()
does. Both the trunk and the 2.2.x brach have the same issue as 2.2.0. It
looks like it got lost on the trunk at between revs 8083 and 8156.
I'm not sure if the id logic in OSprocess has changed over time. if not I
should be able to just pull the code form 2.1 and watch it work. If it has, it
ought not be hard to mimic the logic. If I have time over the weekend, I'll
try it and send a patch.
-------------------- m2f --------------------
Read this topic online here:
http://community.zenoss.com/forums/viewtopic.php?p=20396#20396
-------------------- m2f --------------------
_______________________________________________
zenoss-users mailing list
[email protected]
http://lists.zenoss.org/mailman/listinfo/zenoss-users
