Open Stack

On 06/26/2015 11:00 AM, gordon chung wrote:
> hi,
>
> recently we added a change in Ceilometer to lower the size of our id
> fields in our storage model[1]. the reason we did this was because the
> original size of varchar(255) we assigned to ids were so large that if
> we wanted to generate some of our larger constraint requirements, it
> would hit index limits of the sql backend.
>
> [disclaimer: i'm not an expert on uuid] typically, a uuid is 36 chars
> long, according to google, somtimes a bit longer. in Ceilometer, we
> lowered our size to varchar(128) to get some buffer space, this
> apparently was too restrictive on the ids we use in OpenStack as our
> change started breaking things[2].

Yeah, but come on, is

"arn:openstack:heat::22990abeee3941d8aec34c09bf78d009:stacks/AutoScalingSignalTest-1278811483-JobServerGroup-g3ohap5jraxp-ghgun47tpqcs-6gd2g27t75xy/ead09b07-4fac-45b0-ad9c-489f997925fe"

really a valid resource ID? :(

> so for discussion, i'm hoping to get some conditions (standardisation?)
> on how we generate ids. most people seem to be using uuid4() to generate
> ids -- this seems to be logical. i think the problem seems to be when we
> add namespacing prefix. can we set a cap on namespace prefix? say
> 32char? possibly [<optional 32char prefix>:]uuid4()?
>
> just brainstorming, but my main goal would be to have ids a reasonable
> size (and hopefully consistent).

My suggestion would be to have a pre-processing step that would 
understand that the above monstrosity of a resource identifier can be 
cut into pieces and grab the actual UUID identifier from it in a sane 
way and put that into a VARCHAR(40) field.

Best,
-jay

> [1] https://bugs.launchpad.net/ceilometer/+bug/1353039
> [2] https://bugs.launchpad.net/ceilometer/+bug/1468916
>
> cheers,
>