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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

On Jul 30, 2015, at 10:36 AM, Matt Wringe <mwringe(a)redhat.com&gt; 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.

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(a)lists.jboss.org >> 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 _______________________________________________ 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>

to a URL just needs to url encode the metrics id part. It can be frustrating to a user if ids become policed to be url safe.

On 30 Jul 2015, at 18:38, Michael Burman wrote: > Why are we fighting encoding in 2015? Mainframes had these things Because: a) the recent change of resource id format has broken code in several places where the semantics were not really known and/or implicitly applied Metrics are stored with a [id] while the inventory now only has id and no longer [id]. That must not happen again b) not all consumers/clients are machines. We need to make it easy to consume our services c) the current format of specifying resource data + resource type information may not be what we want going forward. d) we need to ensure that if e.g. ':tag' all of a sudden gets a special meaning in a metric id, clients do not send that as part of a normal id, as metrics or any other part of Hawkular may behave in ways that are not obvious. If we keep what we have fine. But then we need to document it and stick to it in a consistent way all over the place, so that ids or partial urls are/become predictable. _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

But this [id] or id has nothing to do with encoding. It could have just as well been 'hawkular.id' or 'id' and be an issue. This is more

to do with namespacing issue than limiting what characters we could use in the metrics ids. Hawkular-Metrics still returned the exact same name as was written to it. For namespacing (if we want to have

Not to mention the normal browser usage. If the user wants to use easily remembered ids, he should not use generated ones (who could remember uuids if they can't remember encoding rules?). If this is a question of some certain agent then it's still not a global issue.