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

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