when mapping inventory-metric ID to hawkular-metric ID, check if metrid-id property exists about hawkular-client-ruby HOT 6 CLOSED

AFAIK the API doesn't do/use any inventory data to query a metric endpoint. It's left to the developer to decide how to mix inventory/metric data.

We could add this warning to the Readme or we could add the attribute metric_id to Hawkular::Inventory::Metric and set it to metric-id if provided or id if not, so the developer wouldn't need to know about this.
// cc @pilhuhn

from hawkular-client-ruby.

@josejulio Yeah, I think the latter is what @jmazzitelli meant. We always populate a field with metric-id or fall back to id.
I wonder (and this is the other side of my comment on the HWKAGENT-78 jira) if we should not just return this metric-id as id if it exists or otherwise the real id.
I see a potential conflict though for this idea: what if we ever want to update the metric definition - how would we then find the real id on which it is required from inventory. I guess we could have a getter "getId" instead of the :id accessor and make this do the magic. While the update would take the real id, that is still present on the object.

from hawkular-client-ruby.

If is not mandatory for the developer to know the real id of the inventory_metric we could manually implement the attr :id (as getId doesn't seem very ruby-ish) to return the metric_id (if available) so this change would be even more transparent.
In the other hand, if is required for the dev to know the id, replacing it isn't an option and we could have another id (metric_id or native_metric_id, hawkular_metric_id, etc)

from hawkular-client-ruby.

I just commented the following in hwkagent-78, but I will post here too:

Heiko asked "why not directly set the id of the metric definition in inventory to the metric-id here?"

The reason is due to the implementation and how the MeasurementInstance objects are immutable. When the measurement instance IDs are generated, it happens as we build up the Resource using a builder API - this is when we create these instances with our own internal IDs. Once we build the resource, then we pass that instance to our sampling service impl to generate a metric ID and attach it to the measurement instance.

It does not have to work this way. I think we can change the implementation to do something like make the ID mutable and change it - or somehow get the builder to create the ID on the fly somehow. It was just easier implementing it the way it is now. But if this extra "metric-id" property is causing problems and we do not want to have it, we can try to fix it and make it go away.

from hawkular-client-ruby.

Did this ever get fixed? I don't see a related PR documented here.

from hawkular-client-ruby.

Not yet, I've plans on doing it. But haven't setup my env to have a domain eap (and then i'll have to setup a custom metric_id template).
Do you have an environment or config handy ? I'm currently testing with SSl and don't want to do all over again before finishing.

from hawkular-client-ruby.