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

[Thomas Segismont]

+1, the /sync endpoint should persist property changes

If it doesn't, agents will not only have to call the sync endpoint, but to
repost every entity in the tree.

2016-07-26 15:43 GMT+02:00 Jay Shaughnessy <jshaughn at redhat.com>:

>
> 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 listhawkular-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hawkular-dev
>
> _______________________________________________
> hawkular-dev mailing listhawkular-dev at lists.jboss.orghttps://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/20160810/110d422a/attachment.html