<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><span style="color: rgb(160, 160, 168);">On March 4, 2014 at 10:45:02, Vishvananda Ishaya (</span><a href="mailto://vishvananda@gmail.com">vishvananda@gmail.com</a><span style="color: rgb(160, 160, 168);">) wrote:</span></div> <div><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);"><span><div><div><br>On Mar 3, 2014, at 11:32 AM, Jay Pipes <jaypipes@gmail.com> wrote:<span class="Apple-converted-space"> </span><br><br>> On Mon, 2014-03-03 at 11:09 -0800, Vishvananda Ishaya wrote:<span class="Apple-converted-space"> </span><br>>> On Mar 3, 2014, at 6:48 AM, Jay Pipes <jaypipes@gmail.com> wrote:<span class="Apple-converted-space"> </span><br>>><span class="Apple-converted-space"> </span><br>>>> On Sun, 2014-03-02 at 12:05 -0800, Morgan Fainberg wrote:<span class="Apple-converted-space"> </span><br>>>>> Having done some work with MySQL (specifically around similar data<span class="Apple-converted-space"> </span><br>>>>> sets) and discussing the changes with some former coworkers (MySQL<span class="Apple-converted-space"> </span><br>>>>> experts) I am inclined to believe the move from varchar to binary<span class="Apple-converted-space"> </span><br>>>>> absolutely would increase performance like this.<span class="Apple-converted-space"> </span><br>>>>><span class="Apple-converted-space"> </span><br>>>>><span class="Apple-converted-space"> </span><br>>>>> However, I would like to get some real benchmarks around it and if it<span class="Apple-converted-space"> </span><br>>>>> really makes a difference we should get a smart "UUID" type into the<span class="Apple-converted-space"> </span><br>>>>> common SQLlibs (can pgsql see a similar benefit? Db2?) I think this<span class="Apple-converted-space"> </span><br>>>>> conversation. Should be split off from the keystone one at hand - I<span class="Apple-converted-space"> </span><br>>>>> don't want valuable information / discussions to get lost.<span class="Apple-converted-space"> </span><br>>>><span class="Apple-converted-space"> </span><br>>>> No disagreement on either point. However, this should be done after the<span class="Apple-converted-space"> </span><br>>>> standardization to a UUID user_id in Keystone, as a separate performance<span class="Apple-converted-space"> </span><br>>>> improvement patch. Agree?<span class="Apple-converted-space"> </span><br>>>><span class="Apple-converted-space"> </span><br>>>> Best,<span class="Apple-converted-space"> </span><br>>>> -jay<span class="Apple-converted-space"> </span><br>>><span class="Apple-converted-space"> </span><br>>> -1<span class="Apple-converted-space"> </span><br>>><span class="Apple-converted-space"> </span><br>>> 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.<span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>> What does Nova lose here? The proposal is to have Keystone's user_id<span class="Apple-converted-space"> </span><br>> values be UUIDs all the time. There would be a migration or helper<span class="Apple-converted-space"> </span><br>> script against Nova's database that would change all non-UUID user_id<span class="Apple-converted-space"> </span><br>> values to the Keystone UUID values.<span class="Apple-converted-space"> </span><br><br>So I don’t have a problem with keystone internally using uuids, but forcing<span class="Apple-converted-space"> </span><br>a migration of user identifiers isn’t something that should be taken lightly.<span class="Apple-converted-space"> </span><br>One example is external logging and billing systems which now have to be<span class="Apple-converted-space"> </span><br>migrated.<span class="Apple-converted-space"> </span><br><br>I’m not opposed to the migration in principle. We may have to do a similar<span class="Apple-converted-space"> </span><br>thing for project_ids with hierarchical multitenancy, for example. I just<span class="Apple-converted-space"> </span><br>think we need a really good reason to do it, and the performance arguments<span class="Apple-converted-space"> </span><br>just don’t seem good enough without a little empirical data.<span class="Apple-converted-space"> </span><br><br>Vish<span class="Apple-converted-space"> </span></div></div></span></blockquote></div><p>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). </p><p>I am very concerned about the external tools that reference IDs we currently have.</p><p>—Morgan</p></div><p><br></p><p><br></p><div></div></body></html>