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

[John Mazzitelli]

Lukas,

Ignoring identity for a second - it seems to me if I want to change a general property value, it should "just change" when passed to the /sync endpoint. I don't see why it wouldn't. "foo" general property is "1" - now I want to change it to "2" - I send resource up via /sync with the general property "foo=2" - that change should be persisted.

Now, if there are other use cases where identity checks should look at a restricted set of data related to the resource, that's fine. But that to me is separate from what we want /sync to do.

Maybe I just don't understand the issues between the two. But from an outsider's point of view, I would say of the three options you provided in your last email, I choose the third: 

> 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)

This would support what I want in /sync plus support identity checking and traversal - where you said, "This enables us to do the ../identical/.. magic in traversals."


--JohnMazz

----- Original Message -----
> 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
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>