[Hawkular-dev] [inventory] Reading and querying metric type data type

[Thomas Segismont]

Shouldn't we standardize on what Hawkular Metrics uses? 'gauge', 'counter',
'availability'

2016-08-16 17:53 GMT+02:00 Lukas Krejci <lkrejci at redhat.com>:

> Hi all,
>
> while working on [1] I came across an incosistency in how the data type of
> a
> metric type (i.e. gauge, availability, counter, ...) are stored and
> presented.
>
> When you read a metric type using the REST API, you get something like this
> back (some fields ommitted for brevity):
>
> {
>   "path" : "/t;tnt/mt;myMetricType",
>   "unit" : "NONE",
>   "type" : "GAUGE",
>   "collectionInterval" : 0,
>   "id" : "myMetricType"
> }
>
> The metric data type is called "type" here (somewhat confusingly) and
> contains
> the value in upper case.
>
> If you wanted to filter by it, prior to fix to the above mentioned JIRA,
> you
> had to:
>
> /traversal/...;propertyName=__metric_data_type;propertyValue=gauge
>
> Notice 2 things:
> * the name of the property is different
> * the value is in lower case
>
> Now the question is how to bring order to this mess. Because the ideal fix
> will break the format of the data, I'd like to discuss this with the rest
> of
> the team so that we come to a compromise that will amount to the least
> amount
> of work for all the inventory clients.
>
> There are 2 obvious problems here:
> 1) the mismatch between the property name in the JSON output and the
> property
> name used when querying
> 2) the mismatch of the letter case in JSON output and queried property
> value
>
> For 1) I'd like rename BOTH the JSON output and queried property name to
> "metricDataType". We can't "type" because its already taken to mean the
> type
> of the entity and we can't use "__metric_data_type" because it's
> inconsistent
> with the rest of the properties.
>
> For 2) I'd like to consolidate on the upper case usage because that's the
> default Jackson serialization of the enum.
>
> Both of these (and especially 1)) can break existing clients.
>
> What would be the path of least resistance for your usecase?
>
> [1] https://issues.jboss.org/browse/HWKINVENT-192
>
> Thanks,
>
> --
> Lukas Krejci
> _______________________________________________
> 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/20160816/90928ae3/attachment.html