Open Stack

On Fri, Jun 26, 2015 at 12:27 PM, gordon chung <gord at live.ca> wrote:

>
>
> 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.
>
>
Keystone also generates IDs that are in excess of UUID lengths (some are
sha256() hashes, some are partial DNs from LDAP, which have a maximum
length of 255 iirc).

-- Morgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150626/86b64688/attachment.html>