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
__________________________________________________________________________
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
