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

[Jay Shaughnessy]

 From what I understand of the issue, I'd also endorse option 3: 2 
hashes.  This, I think, would provide the most flexibility.  I'd avoid 
option 2 because we don't want to cripple the 'identical' magic.


On 7/25/2016 1:52 PM, John Mazzitelli wrote:
> 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
>>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160726/8878f50d/attachment-0001.html