Open Stack

On 26/06/2015 1:42 PM, Jay Pipes wrote:
> 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.

this is possible, but ideally Ceilometer's processing steps are more to 
derive additional values rather than modify the values given to it[1]. 
it also becomes a bit more daunting because Heat might not be the only 
service generating ids of that length. Currently in Nova and i believe 
Neutron, the id fields are also set at VARCHAR(255). as Ceilometer is 
(mostly) a consumer of data, i don't think we can viably lower our id 
fields until the producers enforce limitations to their own id fields.

[1] the opinion expressed are my own and may not reflect the views of 
the team and community.

cheers,

-- 
gord