Open Stack

On March 4, 2014 at 10:45:02, Vishvananda Ishaya (vishvananda at gmail.com) wrote:

On Mar 3, 2014, at 11:32 AM, Jay Pipes <jaypipes at gmail.com> wrote: 

> On Mon, 2014-03-03 at 11:09 -0800, Vishvananda Ishaya wrote: 
>> On Mar 3, 2014, at 6:48 AM, Jay Pipes <jaypipes at gmail.com> wrote: 
>> 
>>> On Sun, 2014-03-02 at 12:05 -0800, Morgan Fainberg wrote: 
>>>> Having done some work with MySQL (specifically around similar data 
>>>> sets) and discussing the changes with some former coworkers (MySQL 
>>>> experts) I am inclined to believe the move from varchar to binary 
>>>> absolutely would increase performance like this. 
>>>> 
>>>> 
>>>> However, I would like to get some real benchmarks around it and if it 
>>>> really makes a difference we should get a smart "UUID" type into the 
>>>> common SQLlibs (can pgsql see a similar benefit? Db2?) I think this 
>>>> conversation. Should be split off from the keystone one at hand - I 
>>>> don't want valuable information / discussions to get lost. 
>>> 
>>> No disagreement on either point. However, this should be done after the 
>>> standardization to a UUID user_id in Keystone, as a separate performance 
>>> improvement patch. Agree? 
>>> 
>>> Best, 
>>> -jay 
>> 
>> -1 
>> 
>> The expectation in other projects has been that project_ids and user_ids are opaque strings. I need to see more clear benefit to enforcing stricter typing on these, because I think it might break a lot of things. 
> 
> What does Nova lose here? The proposal is to have Keystone's user_id 
> values be UUIDs all the time. There would be a migration or helper 
> script against Nova's database that would change all non-UUID user_id 
> values to the Keystone UUID values. 

So I don’t have a problem with keystone internally using uuids, but forcing 
a migration of user identifiers isn’t something that should be taken lightly. 
One example is external logging and billing systems which now have to be 
migrated. 

I’m not opposed to the migration in principle. We may have to do a similar 
thing for project_ids with hierarchical multitenancy, for example. I just 
think we need a really good reason to do it, and the performance arguments 
just don’t seem good enough without a little empirical data. 

Vish 
Any one of the proposals we’re planning on using will not affect any current IDs.  Since the user_id is a blob, if we start issuing a new “id” format, ideally it shouldn’t matter as long as old IDs continue to work. If we do make any kind of migration for issued IDs I would expect that to be very deliberate and outside of this change set. Specifically this change set would enable multiple LDAP backends (among other user_id uniqueness benefits for federation, etc). 

I am very concerned about the external tools that reference IDs we currently have.

—Morgan





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140304/5f77279b/attachment.html>