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)

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

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@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hawkular-dev _______________________________________________ hawkular-dev mailing listhawkular-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hawkular-dev _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev