----- Mensaje original -----
De: "John Mazzitelli" <mazz(a)redhat.com>
Para: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Enviados: Lunes, 22 de Agosto 2016 22:08:54
Asunto: [Hawkular-dev] change in hawkular wildfly agent platform resource type and metric
type IDs
I realized recently that the Hawkular WildFly Agent generates poorly named
resource type and metric type IDs for the platform resources (e.g. Operation
System, File Store, Memory, Processor, Power Source resource types and their
metrics like "Total Memory" and "Available Memory"). Because all
types must
be stored in Hawkular Inventory at the root level and are all therefore
peers of one another, the names need to be such that they don't risk
collisions with other names now or in the future (e.g. the type name
"Available Memory" is just way to generic for anyone to know what it is,
what resource types it belongs to and risks colliding with other resource
types that may need to define a "Available Memory" metric type in the
future).
This JIRA [1] has been fixed in a PR [2].
I do not think this affects anybody because if the clients are doing "the
right thing" and not hardcoding IDs (tsk tsk if you are), then a normal
querying of resources to get their resource types and metric types will get
you the new IDs without having to change anything.
Besides, I don't think anyone is using the Platform resources now anyway (the
old Hawkular UI did, I think, but I don't think we do in the MiQ stuff).
But I bring this up just in case. Look at your stuff - do you use the
platform resources like Operating System, File Store, Memory, Processor,
etc??? If you do, and you hardcoded IDs, you need to change your code
(better yet, change your code so it doesn't hardcode and use the inventory
API to query the data instead).
To be honest, I do not know.
And this email can be used to spot that we have a lack of integration tests in
hawkular-services so changes like this might impact.
So, I think we need to add from all angles more integration tests to increase a coverage,
then changes like this could be easily tested if those are safe or impact in a different
component.
I know that this is not an easy task, but if we don't start to do it now, it can grow
in an exponential way.
Lucas