Open Stack

Here's how I understand it.  Suppose my username is justin and I'm a member
of 3 projects: project1, project2 and project3

   1. If I log in using the v1.0 API, I hit auth.openstack.org/v1.0 and I
   get X-Server-Management-Url: nova.openstack.org/v1.0/justin.
   2. Presumably that does a 'join across all projects' query on all
   requests so that even if I'm using a v1.0 tool I can see all the servers to
   which I have access (hitting nova.openstack.org/v1.0/justin/servers)
   3. If I log in using the v1.1 API, I hit auth.openstack.org/v1.1 and I
   get X-ServerManagement-Url: nova.openstack.org/v1.1
   4. If I want to query across everything, I append my username to the URL,
   v1.0 style: nova.openstack.org/v1.1/justinsb and get the list of all
   servers hitting nova.openstack.org/v1.1/justin/servers
   5. If I want to see the servers only in project1, I append my project
   name to the URL, so I'd hit nova.openstack.org/v1.1/project1/servers

Is my understanding correct?

However, what I don't understand is how I can query my servers in project1
and project2 (but not those in project3).  The only way I could see is doing
something like this:  nova.openstack.org/v1.1/project1+project2/servers.

I agree that REST paths aren't themselves hacky in the single-project case,
but I don't yet grok the multi-project query.  Of the 3 options I do grok, I
see (c) as the least hacky.

Justin

On Tue, Mar 1, 2011 at 4:46 PM, Monsyne Dragon <mdragon at rackspace.com>wrote:

>  On 3/1/11 6:32 PM, Justin Santa Barbara wrote:
>
> Won't putting this in the URL both:
>
>  1) Break CloudServers API compatibility (a total no-no)?
> and
>
> No. The value is added to the server management url that is reported when
> you login. This is how the current Rackspace cloudservers API handles this.
> (i.e. when you auth and get a token back, the server management url
> returned looks like: http://www.example.org/v1.0/<accountidentifier>/
> the openstack api urls are defined as hanging off of that. )
>
>  2) Preclude us from having e.g. multi-project queries (show me all my
> servers in projects A and B)?
>
> It doesn't really preclude multi-account queries, if they are needed.  You
> would be 'logged in' under a given account, but queries could potentially
> return info based on wider criteria, given user permissions. Also, since the
> server management url is dynamic (see above) it's easy to change that in the
> future if needed.
> .
>
>  The options I see open to us are:
> a) A cookie / header
> b) A query parameter
> c) Something in the request body
>
>  I like (c) because it's the least hacky and is not tied to HTTP.
>
>   Really it's not that hacky. it's basically just nested REST resources.
>
>  Justin
>
>
>
>
>
> On Tue, Mar 1, 2011 at 4:23 PM, Monsyne Dragon <mdragon at rackspace.com>wrote:
>
>> On 3/1/11 6:11 PM, Eric Day wrote:
>>
>> [ ... trimmed ... ]
>>
>>  For the OpenStack API, we need something a bit different from what we
>>> have today. We currently have no way of passing in a project name,
>>> so I propose we add an "entity" element to the path name (just like
>>> Swift does). For example, instead of "/v1.0/servers/1", it would be
>>> "/v1.0/entity/servers/1", where entity can represent an account (like
>>> swift), project (like current nova), or even a user entity (deployments
>>> where projects or accounts are not used). Our window for OpenStack
>>> API changes is still open as it's still under heavy development,
>>> and I think this path addition will provide more functionality and
>>> a consistent structure across services (glance and burrow will be
>>> using an account or "entity" in the path as well).
>>>
>>  FYI:  the multitenant blueprint, which I will be proposing for merge
>> later today or early tomorrow, does just this to pass the project name in.
>>
>> --
>>
>> --
>>    -Monsyne Dragon
>>    work:         210-312-4190
>>    mobile        210-441-0965
>>    google voice: 210-338-0336
>>
>>
>>
>> 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
>>
>
>
>
> --
>
> --
>     -Monsyne Dragon
>     work:         210-312-4190
>     mobile        210-441-0965
>     google voice: 210-338-0336
>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110301/65c364e3/attachment.html>