[Openstack] Feedback on HTTP APIs

George Reese george.reese at enstratus.com
Thu Jun 2 18:24:31 UTC 2011


I understand they are large integer fields. But for consideration of portability, they are strings. 

Sent from my iPhone

On Jun 2, 2011, at 21:14, Jorge Williams <jorge.williams at rackspace.com> wrote:

> 
> On Jun 2, 2011, at 12:18 PM, George Reese wrote:
> 
>> I hate UUIDs with a passion.
>> 
>> * They are text fields, which means slower database indexes
> 
> They are not text fields they are large integers and you should store them as such.  Some databases offer direct support for them. 
> 
>> * They are completely user-unfriendly. The whole "copy and paste" argument borders on silliness
> 
> If you supply links  in the rest api -- you fix the problem of users having to deal with them for the most part.
> 
>> * The bursting scenario makes no sense to me. Why do two different clouds need to agree on uniqueness of resource IDs? (said as one of the few people actually doing bursting)
>> * And uniqueness across regions for "share nothing" can be managed with a variety of alternative options without resorting to the ugliness that is UUIDs
>> 
> 
> Would love to here your ideas on this.
> 
>> On Jun 2, 2011, at 7:40 PM, Glen Campbell wrote:
>> 
>>> 
>>> There was another specific use case, where someone with a private
>>> OpenStack cloud was bursting into a public cloud. UUIDs would help ensure
>>> the uniqueness of identifiers in that case.
>>> 
>>> 
>>> 
>>> On 5/29/11 8:43 PM, "Mark Nottingham" <mnot at mnot.net> wrote:
>>> 
>>>> Ah -- makes sense. Thanks.
>>>> 
>>>> On 30/05/2011, at 11:40 AM, Ed Leafe wrote:
>>>> 
>>>>> On May 29, 2011, at 9:01 PM, Mark Nottingham wrote:
>>>>> 
>>>>>> WIth regards to UUIDs -- I'm not sure what the use cases being
>>>>>> discussed are (sorry for coming in late), but in my experience UUIDs
>>>>>> are good fits for cases where you truly need distributed extensibility
>>>>>> without coordination. In other uses, they can be a real burden for
>>>>>> developers, if for no other reason than their extremely unwieldy
>>>>>> syntax. What are the use cases here?
>>>>> 
>>>>> 
>>>>>    The primary use case I can think of is a deployment with several zones
>>>>> that are geographically dispersed. Since each zone is shared-nothing
>>>>> with other zones, UUIDs are the most logical choice for instance IDs
>>>>> that need to be unique across zones. This is precisely the use case that
>>>>> UUIDs were created for.
>>>>> 
>>>>>    In my experience, UUIDs are no more of a programmatic burden than any
>>>>> other sort of PK; the only place where they are "unwieldy" is when
>>>>> humans have to type them into a command line or a browser URL. But since
>>>>> most humans doing that would have access to copy/paste, it isn't nearly
>>>>> as bad as it might seem.
>>>>> 
>>>>> 
>>>>> 
>>>>> -- Ed Leafe
>>>>> 
>>>>> 
>>>>> 
>>>>> Confidentiality Notice: This e-mail message (including any attached or
>>>>> embedded documents) is intended for the exclusive and confidential use
>>>>> of the
>>>>> individual or entity to which this message is addressed, and unless
>>>>> otherwise
>>>>> expressly indicated, is confidential and privileged information of
>>>>> Rackspace.
>>>>> Any dissemination, distribution or copying of the enclosed material is
>>>>> prohibited.
>>>>> If you receive this transmission in error, please notify us immediately
>>>>> by e-mail
>>>>> at abuse at rackspace.com, and delete the original message.
>>>>> Your cooperation is appreciated.
>>>>> 
>>>> 
>>>> --
>>>> Mark Nottingham   http://www.mnot.net/
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to     : openstack at lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help   : https://help.launchpad.net/ListHelp
>>> 
>>> 
>>> 
>>> Confidentiality Notice: This e-mail message (including any attached or
>>> embedded documents) is intended for the exclusive and confidential use of the
>>> individual or entity to which this message is addressed, and unless otherwise
>>> expressly indicated, is confidential and privileged information of Rackspace.
>>> Any dissemination, distribution or copying of the enclosed material is prohibited.
>>> If you receive this transmission in error, please notify us immediately by e-mail
>>> at abuse at rackspace.com, and delete the original message.
>>> Your cooperation is appreciated.
>>> 
>>> 
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack at lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>> 
>> --
>> George Reese - Chief Technology Officer, enStratus
>> e: george.reese at enstratus.com    t: @GeorgeReese    p: +1.207.956.0217    f: +1.612.338.5041
>> enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com
>> To schedule a meeting with me: http://tungle.me/GeorgeReese
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
> 




More information about the Openstack mailing list