Open Stack

We shouldn't keep tainting this argument with concerns about whether the IDs are readable or not.  We have UIs and CLIs to make things readable for humans.

We have to accept that, on the scales we care about, any unique ID is going to be incomprehensible to a human.  Rely on your presentation layer, that's what it's there for!

Ewan.

> -----Original Message-----
> From: openstack-bounces+ewan.mellor=citrix.com at lists.launchpad.net
> [mailto:openstack-bounces+ewan.mellor=citrix.com at lists.launchpad.net]
> On Behalf Of Sandy Walsh
> Sent: 23 March 2011 12:30
> To: openstack at lists.launchpad.net
> Subject: Re: [Openstack] Instance IDs and Multiple Zones
> 
> Good conversation guys. Certainly something we need to get settled out
> sooner than later.
> 
> On naming:
> 
> No matter how we shake it out (prefixes, mac address, time, etc), we're
> essentially fabricating our own form of UUID ... trying to pick some
> unique qualifier(s) to avoid collisions.
> 
> I think the real driver is making something that is as-short-as-
> possible and mnemonic enough that a user could look at it and say "yup,
> that's mine". Personally, I find UUID's to be ugly monsters and think
> URN's are better for providing a mnemonic for remembering names.
> 
> Given: "6373-ba62-9847-feab-b72a-00dd" vs.
> "rax:ord:zone3:rack2:cust29:inst383" ... give me a URN anytime.
> However, this does pose security risks by exposing internal layouts.
> 
> We currently allow a user supplied friendly name but under-the-hood use
> the instance ID. Since customers use different auth credentials their
> instances live in different Projects and there is no conflict.
> Duplicate names are allowed across customers (even within customers?)
> Downside is there are no hints for routing from names.
> 
> On bursting:
> 
> Currently, the Instance ID is fabricated in the zone where the create()
> call was handled. This Instance ID is treated like a Reservation #
> which is returned to the user for later follow-up (since provisioning
> can take a while).
> 
> The way I currently envision bursting with zones is that the commercial
> zones would be the leaf zones in a deployment. That is, instances would
> be provisioned locally first (depending on Server Best Match) due to
> their low weight scores and ultimately "burst" through the bottom of
> the zone tree to the commercial cloud.
> 
> I think this works well. If I have a hybrid cloud and issue 'nova list'
> I would see something like:
> 
> "sleepy" - com:myco:development:inst1
> "dopey" - com:myco:development:inst2
> "blinky" - com:myco:development:inst3
> "inky" - rax:ord:zone3:rack2:cust293:inst393
> "pinky" - rax:ord:zone2:rack34:cust293:inst8746
> "clyde" - bobscloud:basement:shelf2:cust9:inst8
> 
> and get a good idea of what's what.
> 
> 
> 
> 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