Open Stack

I like this idea, but I have some concerns about the feasibility of successfully differentiating between users and projects. While it's easy to query one data store and then the next, perhaps we can avoid this issue by assigning unique identifiers to resources?

Show all servers in project1:
 GET http://nova.openstack.org/v1.1/servers?project=project1

Show "Instance X":
 GET http://nova.openstack.org/v1.1/servers/-F5*ovBi-=rYdW3leIGY

Show all servers available to current user:
 GET http://nova.openstack.org/v1.1/servers

Unique identifiers for items, while many feel they are cumbersome, provide a couple benefits I can think of off the top of my head:

1) Easy permalinks (ability to re-name everything else about the server without worrying about the URL changing)

2) Public URLs no longer need any other identifying information because they are now unique.

Problems include things like me not knowing the intricacies of the OpenStack database which might make my first example more difficult. Also, some people like URLs to be readable and/or memorable.


-----Original Message-----
From: "Eric Day" <eday at oddments.org>
Sent: Tuesday, March 1, 2011 9:14pm
To: "Justin Santa Barbara" <justin at fathomdb.com>
Cc: openstack at lists.launchpad.net
Subject: Re: [Openstack] Entities in OpenStack Auth

For that query you would, but not all. If you want to create a new
instance for project1 you would:

nova.openstack.org/v1.1/project1/servers

Or if you wanted to reboot instance X in project1:

nova.openstack.org/v1.1/project1/servers/X

Note that the following resource is not the same as the last, since
justin wouldn't be the owner for instance X, project1 would be:

nova.openstack.org/v1.1/justin/servers/X

I think searches will always have special cases with filter options,
but for identifying a canonical URL for a resource, having the entity
name of the owner in there seems correct.

The main thing I'm trying to figure out is whether to use an extra
entity in the path for new service URLs. Swift does and Nova does not,
and it would be nice to have some consistency. I see the benefits of
both, and in Swift's case it needs to for simple public URLs (where
there is no user context).

-Eric

On Tue, Mar 01, 2011 at 06:00:12PM -0800, Justin Santa Barbara wrote:
>    If we're always going to pass the same user-id token (for a particular
>    user), what's the value in passing it at all?  Why not get it from the
>    authentication token?
>    e.g. my X-Auth-Token could look like:  "justinsb
>    project1,project2,project3 5OPr9UR2xk32K9ArAjO562e" (i.e. my username,
>    projects and a crypto signature)
>    Justin
> 
>    On Tue, Mar 1, 2011 at 5:51 PM, Eric Day <eday at oddments.org> wrote:
> 
>      Hi Justin,
>      On Tue, Mar 01, 2011 at 05:14:42PM -0800, Justin Santa Barbara wrote:
>      >    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.
> 
>      I would probably say use nova.openstack.org/v1.1/justin/servers with
>      one or more filter parameters in the URL or body as you mention. This
>      something to consider across all services, not just nova. AFAIK
>      Swift doesn't support queries across multiple accounts right now,
>      so I'd like to hear their thoughts on it as well.
>      -Eric

_______________________________________________
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