<div dir="ltr"><div>+1, the /sync endpoint should persist property changes<br><br></div><div>If it doesn't, agents will not only have to call the sync endpoint, but to repost every entity in the tree.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-07-26 15:43 GMT+02:00 Jay Shaughnessy <span dir="ltr"><<a href="mailto:jshaughn@redhat.com" target="_blank">jshaughn@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<p><font face="Calibri">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.</font><br>
</p><div><div class="h5">
<br>
<div>On 7/25/2016 1:52 PM, John Mazzitelli
wrote:<br>
</div>
<blockquote type="cite">
<pre>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:
</pre>
<blockquote type="cite">
<pre>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)
</pre>
</blockquote>
<pre>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 -----
</pre>
<blockquote type="cite">
<pre>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
______________________________<wbr>_________________
hawkular-dev mailing list
<a href="mailto:hawkular-dev@lists.jboss.org" target="_blank">hawkular-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a>
</pre>
</blockquote>
<pre>______________________________<wbr>_________________
hawkular-dev mailing list
<a href="mailto:hawkular-dev@lists.jboss.org" target="_blank">hawkular-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>______________________________<wbr>_________________<br>
hawkular-dev mailing list<br>
<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a><br>
<br></blockquote></div><br></div>