<div dir="ltr">Shouldn't we standardize on what Hawkular Metrics uses? 'gauge', 'counter', 'availability'<br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-08-16 17:53 GMT+02:00 Lukas Krejci <span dir="ltr"><<a href="mailto:lkrejci@redhat.com" target="_blank">lkrejci@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
while working on [1] I came across an incosistency in how the data type of a<br>
metric type (i.e. gauge, availability, counter, ...) are stored and presented.<br>
<br>
When you read a metric type using the REST API, you get something like this<br>
back (some fields ommitted for brevity):<br>
<br>
{<br>
"path" : "/t;tnt/mt;myMetricType",<br>
"unit" : "NONE",<br>
"type" : "GAUGE",<br>
"collectionInterval" : 0,<br>
"id" : "myMetricType"<br>
}<br>
<br>
The metric data type is called "type" here (somewhat confusingly) and contains<br>
the value in upper case.<br>
<br>
If you wanted to filter by it, prior to fix to the above mentioned JIRA, you<br>
had to:<br>
<br>
/traversal/...;propertyName=__<wbr>metric_data_type;<wbr>propertyValue=gauge<br>
<br>
Notice 2 things:<br>
* the name of the property is different<br>
* the value is in lower case<br>
<br>
Now the question is how to bring order to this mess. Because the ideal fix<br>
will break the format of the data, I'd like to discuss this with the rest of<br>
the team so that we come to a compromise that will amount to the least amount<br>
of work for all the inventory clients.<br>
<br>
There are 2 obvious problems here:<br>
1) the mismatch between the property name in the JSON output and the property<br>
name used when querying<br>
2) the mismatch of the letter case in JSON output and queried property value<br>
<br>
For 1) I'd like rename BOTH the JSON output and queried property name to<br>
"metricDataType". We can't "type" because its already taken to mean the type<br>
of the entity and we can't use "__metric_data_type" because it's inconsistent<br>
with the rest of the properties.<br>
<br>
For 2) I'd like to consolidate on the upper case usage because that's the<br>
default Jackson serialization of the enum.<br>
<br>
Both of these (and especially 1)) can break existing clients.<br>
<br>
What would be the path of least resistance for your usecase?<br>
<br>
[1] <a href="https://issues.jboss.org/browse/HWKINVENT-192" rel="noreferrer" target="_blank">https://issues.jboss.org/<wbr>browse/HWKINVENT-192</a><br>
<br>
Thanks,<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Lukas Krejci<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>
</font></span></blockquote></div><br></div>