[Hawkular-dev] [Inventory] What constitutes a "syncable" change of an entity?

[Lukas Krejci]

Hi all,

tl;dr: This probably only concerns Mazz and Austin :)

The subject is a little bit cryptic, so let me explain - this deals with 
inventory sync and what to consider a change that is worth being synced on an 
entity.

Today whether an entity is update during sync depends on whether some of this 
"vital" or rather "identifying" properties change. Namely:

Feed: only ID and the hashes of child entities are considered
ResourceType: only ID and hashes of configs and child operation types are  
              considered
MetricType: id + data type + unit 
OperationType: id + hashes of contained configs (return type and param types)
Metric: id
Resource: id + hashes of contained metrics, contained resources, config and 
          connection config 

>From the above, one can see that not all changes to an entity will result in 
the change being synchronized during the /sync call, because for example an 
addition of a new generic property to a metric doesn't make its identity hash 
change.

I start to think this is not precisely what we want to happen during the /sync 
operation.

On one hand, I think it is good that we still can claim 2 resources being 
identical, because their "structure" is the same, regardless of what the 
generic properties on them look like (because anyone can add arbitrary 
properties to them). This enables us to do the ../identical/.. magic in 
traversals.

On the other hand the recent discussion about attaching an h-metric ID as a 
generic property to a metric iff it differs from its id/path in inventory got 
me thinking. In the current set up, if agent reported that it changed the h-
metric ID for some metric, the change would not be persisted, because /sync 
would see the metric as the same (because changing a generic property doesn't 
change the identity hash of the metric).

I can see 3 solutions to this:

* formalize the h-metric ID in some kind of dedicated structure in inventory 
that would contribute to the identity hash (i.e. similar to the "also-known-
as" map I proposed in the thread about h-metric ID)

* change the way we compute the identity hash and make it consider everything 
on an entity to contribute (I'm not sure I like this since it would limit the 
usefulness of ../identical/.. traversals).

* compute 2 hashes - 1 for tracking the identity (i.e. the 1 we have today) 
and a second one for tracking changes in content (i.e. one that would consider 
any change)

Fortunately, none of the above is a huge change. The scaffolding is all there 
so any of the approaches would amount to only a couple of days work.

WDYT?

-- 
Lukas Krejci