Open Stack

Hi Brian,

The proposal abstracts 'users' and 'projects' to just 'entities',
although we may want to use 'accounts' since this already maps to how
swift works. So a user is an account, a project is an account, and
accounts can give access to other accounts (possibly with specific
roles). Therefore the query to list all servers in "project1" is
really deployment specific, and could just be:

GET http://nova.openstack.org/v1.1/project1/servers

Which is just an application of the generic:

GET http://nova.openstack.org/v1.1/<account>/servers

As I mentioned before, we'll probably want search options for depth
so it can include nested accounts and filters. For example:

GET http://nova.openstack.org/v1.1/user1/servers?depth=2&filter=proj1,proj2

Here user1, proj1, and proj2 are all account names.

As for unique IDs, this again is something we should probably try to
be consistent on across services. With nova today, ID's are only unique
within a cluster (shared DB instance), so two clusters would currently
clash. We need something more than just a unique ID when we start
connecting public and private clouds. You can't control the unique ID
generation so a bad private cloud could start duplicating 'unique'
ID's on purpose. We need some namespace to prevent these collisions
and limit the damage, and account seems like the most appropriate
(and matches what Swift does, so there is some consistency).

-Eric

On Wed, Mar 02, 2011 at 01:45:43PM -0500, Brian Lamar wrote:
> 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
>