<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 26, 2015 at 12:27 PM, gordon chung <span dir="ltr"><<a href="mailto:gord@live.ca" target="_blank">gord@live.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
<br>
On 26/06/2015 1:42 PM, Jay Pipes wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On 06/26/2015 11:00 AM, gordon chung wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
hi,<br>
<br>
recently we added a change in Ceilometer to lower the size of our id<br>
fields in our storage model[1]. the reason we did this was because the<br>
original size of varchar(255) we assigned to ids were so large that if<br>
we wanted to generate some of our larger constraint requirements, it<br>
would hit index limits of the sql backend.<br>
<br>
[disclaimer: i'm not an expert on uuid] typically, a uuid is 36 chars<br>
long, according to google, somtimes a bit longer. in Ceilometer, we<br>
lowered our size to varchar(128) to get some buffer space, this<br>
apparently was too restrictive on the ids we use in OpenStack as our<br>
change started breaking things[2].<br>
</blockquote>
<br>
Yeah, but come on, is<br>
<br>
"arn:openstack:heat::22990abeee3941d8aec34c09bf78d009:stacks/AutoScalingSignalTest-1278811483-JobServerGroup-g3ohap5jraxp-ghgun47tpqcs-6gd2g27t75xy/ead09b07-4fac-45b0-ad9c-489f997925fe" <br>
<br>
really a valid resource ID? :(<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
so for discussion, i'm hoping to get some conditions (standardisation?)<br>
on how we generate ids. most people seem to be using uuid4() to generate<br>
ids -- this seems to be logical. i think the problem seems to be when we<br>
add namespacing prefix. can we set a cap on namespace prefix? say<br>
32char? possibly [<optional 32char prefix>:]uuid4()?<br>
<br>
just brainstorming, but my main goal would be to have ids a reasonable<br>
size (and hopefully consistent).<br>
</blockquote>
<br>
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.<br>
</blockquote>
<br></span>
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.<br>
<br></blockquote><div><br></div><div>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).</div><div><br></div><div>-- Morgan</div></div><br></div></div>