[Hawkular-dev] change in hawkular wildfly agent platform resource type and metric type IDs

Lucas Ponce lponce at redhat.com
Tue Aug 23 03:16:30 EDT 2016



----- Mensaje original -----
> De: "John Mazzitelli" <mazz at redhat.com>
> Para: "Discussions around Hawkular development" <hawkular-dev at 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

> --John Mazz
> 
> [1] JIRA: https://issues.jboss.org/browse/HWKAGENT-133
> [2] PR: https://github.com/hawkular/hawkular-agent/pull/246
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 


More information about the hawkular-dev mailing list