On Jul 30, 2015, at 10:36 AM, Matt Wringe <mwringe@redhat.com> wrote:



On 30/07/15 10:07 AM, John Mazzitelli wrote:
To explain that those MI~R and AI~R things are. Its simple, and done for a reason (I do do things for actual reasons - I didn't just arbitrarily throw letters together :) - but it is not necessary these IDs stay this way (the reason was for easier debugging and reading the logs).

First, realize these are ONLY identifiers for metric instances (that is, metric instance definitions assigned to resources). They are not resource IDs, or metric type IDs. Only metric instance IDs.

The syntax is:

MI~R~[%1]~MT~%2

or

AI~R~[%1]~AT~%2

Where "MI" refers to "MeasurementInstance" and "AI" means "AvailInstance" - that's a distinction made only in the agent. These have two parts - a resource and a type.

The ~R~ just means "the next thing coming is the resource ID."

And that next thing is [%1] where %1 is the resource ID that is associated with this metric instance. (I wrap in brackets so its easy to pick out when debugging or reading the logs - I think the UI might even use a hack to expect that to wrap the ID, even though it shouldn't be doing that - these IDs should be opaque).

The next is either ~MT~ (MT meaning "Metric Type") or ~AT~ (meaning "Avail Type" - again, a distinction only in the agent - they are all "metric types" in inventory) which just means "the next thing coming is the metric type ID.

%2 is the metric type ID

I will say all that extra stuff is helpful when reading them in the logs, which is the sole reason why I did it - when I see "AI~R~[blah]~AT~[boo]" in the log I know exactly what it is referencing ("an availability metric on resource blah whose type is boo") - no need to guess or root through the logs and inventory storage to find out what those are. Very easy to debug.

All that said (now that I've defended my reasons for the magic constants :), we can change this to whatever we want SO LONG AS it is unique, obviously. I can get rid of all that extra stuff. We can definitely get rid of the "[" "]" - those where just to make it easy to pick out the resource ID (unless the UI expects those too). We can change the "~" to something else or remove them. We can remove the "AI", "MI", "AT", "MT", and "R" if its too verbose. In fact, none of this ID is "necessary" internally other than it needs to be unique (it is "nice" for debugging and reading logs, that is all).

The resource ID, however, has three parts itself and those are separated by a required "~" but that is only due to a hack we needed to get that "execute operations" feature to work in the latest alpha (the server assumes the resource ID's first part is the feed ID, and the feed ID is separated from the rest with "~" - but once we get rid of that hack, the resource ID can again be changed to whatever syntax we want so long as it is unique.

From a metrics perspective, the id should be any string that a client 
wants to use. Since it can be any string, then any tools which do a call 
to a URL just needs to url encode the metrics id part.

This might be somewhat of a separate issue, but we need to introduce some reserved characters that users are not allowed to use for metric ids and tag names. I haven’t yet written up a ticket with the details, but the reason is because we will be generating metrics/time series and use some “internal” tags. We need at least one reserved character to make sure we avoid naming conflicts between user ids/names and system generated ones.


It can be frustrating to a user if ids become policed to be url safe. 
All this is going to do is force the client developer to url encode the 
metric id themselves, especially if part of the metric id contains some 
user generated value (say the name of a container, which is allowed to 
have url unsafe characters).

But, the metric id should really just be an identifier. Encoding data 
into the id and then parsing it out doesn't seem right. Maybe that other 
data could be added as a 'tag' or maybe we need some other mechanism to 
store this information.


--John Mazz

----- Original Message -----
Hey,

we currently have a pretty ad-hoc resource naming scheme,
that involves magic constants like "MI~R" or "AI~R"
and also sometimes square brackets '[' and ']', which are
even invalid characters (if not escaped) inside a URL [1].

A recent switch from resource naming with [] to one without
[] created a bit of a mess, as the metric names still expect
the [] and probably other clients that are not part of the
github.com/hawkular repositories


We need to revisit and fix the resource types
(e.g. supply WildFly base data from within the Hawkular server)
and the resources using those including names of
metric definitions , operation definitions etc in Alpha4
before too much code relies on it.

Similar I believe that resource info should not contain
the full type information every time - only if explicitly
requested. Clients should be able to get the type info
by following a link that is supplied in the resource info.

On top of that we need to publish how client writers
can get the data they need.


[1] https://issues.jboss.org/browse/HAWKULAR-491
_______________________________________________
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

_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev