On Aug 17, 2016, at 12:48 PM, Thomas Segismont <tsegismo@redhat.com> wrote:I don't believe Metrics manages units. If it does I would expect user can submit values ignoring case._______________________________________________2016-08-17 11:32 GMT+02:00 Lukas Krejci <lkrejci@redhat.com>:On Tuesday, August 16, 2016 6:18:51 PM CEST Thomas Segismont wrote:
> Shouldn't we standardize on what Hawkular Metrics uses? 'gauge', 'counter',
> 'availability'
>
Which brings me to another question... How do you represent units of the
metrics, if at all?
Inventory right now uses again an uppercase representation of them defined in
https://github.com/hawkular/hawkular-inventory/blob/ master/hawkular-inventory-api/ src/main/java/org/hawkular/ inventory/api/model/ MetricUnit.java
> 2016-08-16 17:53 GMT+02:00 Lukas Krejci <lkrejci@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@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
--
Lukas Krejci
_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev