Hi,
I'm in the process of completely revising how updates are made to the
nanoprobes (drones) and also to the database. It's the result of some
fairly major thinking about how to do this. I mentioned it on my blog
and we had a little discussion of it on the mailing list. [The current
discovery update code is really a prototype - to let me learn about
updating graph databases].
I wrote the (easy) part of adding transactions for updating the drones -
and it looks like it is working. Because of how significant this is,
I've done more testing than normal before pushing it upstream, and I'll
do some more. [Still not persisting the transactions, but by
comparison, that's easy].
Once I'm happy with this, I'll tackle the much more interesting (read
"challenging") task of describing the database updates, and putting them
into the transaction structure. Representing them properly is
interesting, but actually committing the transaction descriptions will
be even more interesting.
The problem is that graphs are not hierarchies - but some subgraphs in
our graph are hierarchical - with ownership from the top, and certain of
the updates are naturally hierarchical. For example, when I get a
network configuration discovery packet, it describes NICs and MAC
addresses, and IP addresses - all of which it is authoritative on, and
all of which are hierarchically "owned" by the server that they are
associated with. [and what about that nasty NIC renaming problem - when
you update things NIC names may play musical chairs].
When I get a network discovery update, I need to reshape that portion of
the graph (this hierarchy) to exactly match the discovery information.
So, if before this server had three NICs, and now it has two, I need to
make it now have two (preferably the right two). Similarly for IP
addresses - but not quite the same. An IP address can move from one
machine to another pretty quickly - and there's no guarantee of the
order of the updates. Will the addition of the IP to the new machine
come first? Or will the deletion from the old one?
So, this will give me some more food for thought as I think how to do
this right - as opposed to how it's done now :-).
I don't yet understand all the cases - so I'll have to think about this
some more before I write that code.
But one nice thing about this - it will likely make writing the graph
update code for the discovery plugins MUCH easier than now. The work
will be divided between two parts:
Describing the update
Performing the update
Currently it just does the update. These new methods of describing the
update will simplify that code - and make it where you only have to
understand the schema that goes with the discovery data, and the code
for performing the update shouldn't have to know anything about the
discovery data.
It will be a win - but more work than currently.
--
Alan Robertson <[email protected]> - @OSSAlanR
"Openness is the foundation and preservative of friendship... Let me claim
from you at all times your undisguised opinions." - William Wilberforce
_______________________________________________
Assimilation mailing list - Discovery-Driven Monitoring
[email protected]
http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation
http://assimmon.org/
