[openstack-dev] [ceilometer][all] the max length of an id

Morgan Fainberg morgan.fainberg at gmail.com
Sat Jun 27 00:01:41 UTC 2015

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>

More information about the OpenStack-dev mailing list