On 4 May 2015, at 14:03, Lukas Krejci wrote:
In my mind almost anything "is changing like a metric",
because
everything changes over time.
Well. Then lets stop your project and make metrics store inventory
data :;->
Also IMHO "key-value pairs" are just JSON. I think that
the
structured data
support for configs and operation params served us well in RHQ.
I don't say that the structured data in RHQ is by itself bad (the
implementation
has IMO room for improvement). I also don't say that the traits in RHQ
are a bad thing.
But: with traits and configuration we have some very similar concepts
that have in RHQ some very different implementation.
So IMHO we need a time-series store for structured data. I am not
sure
inventory
is that - it is good for storing relationships among entities but I
am not
sure if it is well suited for storing (versioned) structured data.
I do not think that each single property needs to be a separate object.
I can imagine that we keep one (JSON) object per version (with some
additional
metadata) and the respective "client" of the store know how to deal with
it.
My understanding was that Inventory can have such a list of things
hanging on a resource.
The question remains though if inventory is the right place or metrics.
Also for Traits, I think we should not (like for Availability) store the
whole
string every 20sec, but only store an update when a change occurred (1),
which may or may be applicable for configuration too. In fact RHQ had
logic inside the agents to only send updates when it detected changes.
Also Traits are most likely r/o, while configuration data may be
modified from
the UI.
1) And perhaps the last time the old version was still detected.