10:53 a.m.
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
11:18 a.m.
Shouldn't we standardize on what Hawkular Metrics uses? 'gauge',
'counter',
'availability'
2016-08-16 17:53 GMT+02:00 Lukas Krejci <lkrejci(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
2:33 a.m.
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'
Yeah, my suggestion to keep it uppercase was caused by a) ignorance about what
metrics use and b) not knowing how to affect the enum serialization in
Jackson.
Now that I know both, we can do that ;) Consistent naming across components is
certainly a plus.
On the other hand that is yet another breakage for the existing inventory
clients.
2016-08-16 17:53 GMT+02:00 Lukas Krejci <lkrejci(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
--
Lukas Krejci
2:53 a.m.
You should be able to ignore case actually. Have a look at Metrics' Jackson
deserializer and JAX-RS param converter.
2016-08-17 9:33 GMT+02:00 Lukas Krejci <lkrejci(a)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'
>
Yeah, my suggestion to keep it uppercase was caused by a) ignorance about
what
metrics use and b) not knowing how to affect the enum serialization in
Jackson.
Now that I know both, we can do that ;) Consistent naming across
components is
certainly a plus.
On the other hand that is yet another breakage for the existing inventory
clients.
> 2016-08-16 17:53 GMT+02:00 Lukas Krejci <lkrejci(a)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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
--
Lukas Krejci
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
4:32 a.m.
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-inven...
2016-08-16 17:53 GMT+02:00 Lukas Krejci <lkrejci(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
--
Lukas Krejci
11:48 a.m.
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(a)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(a)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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
--
Lukas Krejci
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
11:58 a.m.
Metrics does not manage units. Units can be specified as metric tags, but we don’t do any
special handling like converting MB —> KB for example.
On Aug 17, 2016, at 12:48 PM, Thomas Segismont
<tsegismo(a)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(a)redhat.com
<mailto: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-inven...
<https://github.com/hawkular/hawkular-inventory/blob/master/hawkular-inven...
> 2016-08-16 17:53 GMT+02:00 Lukas Krejci <lkrejci(a)redhat.com
<mailto: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
<https://issues.jboss.org/browse/HWKINVENT-192>
> >
> > Thanks,
> >
> > --
> > Lukas Krejci
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev(a)lists.jboss.org <mailto:hawkular-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
<https://lists.jboss.org/mailman/listinfo/hawkular-dev>
--
Lukas Krejci
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org <mailto:hawkular-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hawkular-dev
<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
12:55 p.m.
Could you maintain "type" in the JSON and support for the
"__metric_data_type " filter for some short deprecation period? And
then add "metricDataType" to the json and a new metricDataType filter?
Then we can actively update our uses of the deprecated API and anyone
else will also have a chance to do so as well.
On 8/16/2016 11:53 AM, Lukas Krejci wrote:
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,
2952
days inactive
2953
days old
7 comments
4 participants
participants (4)
-
Jay Shaughnessy -
John Sanda -
Lukas Krejci -
Thomas Segismont