Re: [Hawkular-dev] Revisit resource naming + resource types for Alpha4

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>