openstack team mailing list archive

[Brian Schott <brian.schott@xxxxxxxxxxxxxxxxxx>]

Ahhh..  OK. The namespace is embedded in the instance ID depending on the type, so it should be sufficient to: 
GET /servers/<instance uuid>
Regardless, uuid is sufficient and globally unique.

This doesn't consider authentication.  I'd assumed that username and realm and the like had been handled by REST-based authentication and would be available to the API service.  

-------------------------------------------------
Brian Schott, CTO
Nimbis Services, Inc.
brian.schott@xxxxxxxxxxxxxxxxxx
ph: 443-274-6064  fx: 443-274-6060







On Jul 11, 2011, at 2:04 PM, Eric Day wrote:

> On Mon, Jul 11, 2011 at 05:17:05PM +0000, Sandy Walsh wrote:
>> How is
>> 
>> nova-<account>-<instance uuid>
>> 
>> any different than:
>> 
>> AAAABBBB-CCCC-DDDD-EEEE-FFFFGGGGHHHH
>> 
>> Where AAAA/BBBB/CCCC (or some subset of them) are reserved/regulated?
> 
> Nothing, if DDDD-EEEE-FFFFGGGGHHHH is a full UUID. If we compare to
> swift, the account prefix is a UUID too. The account prefix could be
> fixed for a session or passed in to every request depending on how
> things are decided. For example:
> 
> GET /servers/<account id>/<instance uuid>
> 
> where account ID could be a domain, uuid, etc. Another way to pass
> the namespace is through part of the token:
> 
> GET /servers/<instance uuid>
> Token: <token tied to a specific account>
> 
> The latter is simpler but less flexible since it may not allow for
> operations on instances outside of the account the token was created
> for. I'm a bit out of the loop on those type of API decisions right
> now, so I'll stop there. :)
> 
> -Eric
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

Attachment: smime.p7s
Description: S/MIME cryptographic signature