<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 6, 2016 at 7:06 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 05/10/16 07:55 AM, Sean Dague wrote:<br>
> Except... the 64 char field in keystone isn't required to be a uuid4.<br>
> Which we ran into when attempting to remove it from the URLs in Nova.<br>
> There is no validation anywhere that requires that of keystone values.<br>
><br>
> For instance, Rackspace uses ints.<br>
<br>
</span>yeah, that's basically why we had to revert our attempt in Ceilometer.<br>
we tried to enforce uuid with some buffer and it was too difficult to<br>
track down every one we broke.<br>
<span class=""><br>
><br>
> Yes this is debt. And yes, a few things would be nicer if this was more<br>
> constrained, but as was recently stated on twitter, we've been calling<br>
> the 9th month the seventh month for 2000 years -<br>
> <a href="https://twitter.com/GonzoHacker/status/781890649444519937" rel="noreferrer" target="_blank">https://twitter.com/<wbr>GonzoHacker/status/<wbr>781890649444519937</a>. Some times<br>
> the cost of fixing the thing really just isn't worth the potential<br>
> breaks to operators that were operating within the old constraints fine.<br>
<br>
</span>i think this sums up my feeble attempt at initiating this as a cross<br>
project topic a while back. too many projects, too few participants, too<br>
little gain. we avoided the issue in Gnocchi and the original reason i<br>
brought it up became less important.<br>
<br>
it'd be nice if we could somehow enforce new attributes/columns to<br>
follow uuid standards in hopes that older stuff just eventually dies<br>
off. that said, i'm guessing stuff like user_id and project_id columns<br>
are sticking around for a while...<br>
<br>
cheers,<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
gord<br>
</font></span><div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>The SHA256() rendering that does not conform to UUID is required to identify federated identity users and easily map them to the correct identity backend(s). It means that "UUID" standards cannot be used. Partly this requirement comes from needing to be able to programmatically generate the ID for external consumers since the ID is "Element of ID from IDP" and "Domain ID" and SHA256() hash of these two data elements.</div><div><br></div><div>The older legacy information such as LDAP partial DNs should in the long term eventually go away if the current path continues. Project IDs will likewise become more and more consistent as long as Keystone's upstream code is used as LDAP-stored projects no longer exists and Project IDs are always generated by Keystone (cannot be user supplied).</div><div><br></div><div>In short, user_id is a little bit more flexible than project id with older installations potentially having some legacy data. New installations (barring custom driver code) should be much more consistent.</div><div><br></div><div>The original part of this thread talking about project name length, it is largely historic and could be changed. 64 was convenient and fits nicely in UI; there is no specific technical reason this was limited to 64. It falls on Steve and the rest of the Keystone team to determine if the request for longer project_names outweighs the design/usability of the current length.</div></div></div></div>