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,
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
