Open Stack

On Thu, Oct 6, 2016 at 7:06 AM, gordon chung <gord at live.ca> wrote:

>
>
> On 05/10/16 07:55 AM, Sean Dague wrote:
> > Except... the 64 char field in keystone isn't required to be a uuid4.
> > Which we ran into when attempting to remove it from the URLs in Nova.
> > There is no validation anywhere that requires that of keystone values.
> >
> > For instance, Rackspace uses ints.
>
> yeah, that's basically why we had to revert our attempt in Ceilometer.
> we tried to enforce uuid with some buffer and it was too difficult to
> track down every one we broke.
>
> >
> > Yes this is debt. And yes, a few things would be nicer if this was more
> > constrained, but as was recently stated on twitter, we've been calling
> > the 9th month the seventh month for 2000 years -
> > https://twitter.com/GonzoHacker/status/781890649444519937. Some times
> > the cost of fixing the thing really just isn't worth the potential
> > breaks to operators that were operating within the old constraints fine.
>
> i think this sums up my feeble attempt at initiating this as a cross
> project topic a while back. too many projects, too few participants, too
> little gain. we avoided the issue in Gnocchi and the original reason i
> brought it up became less important.
>
> it'd be nice if we could somehow enforce new attributes/columns to
> follow uuid standards in hopes that older stuff just eventually dies
> off. that said, i'm guessing stuff like user_id and project_id columns
> are sticking around for a while...
>
> cheers,
>
> --
> gord
>
>
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.

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).

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161006/46f4c65d/attachment.html>