On Fri, Mar 04, 2011 at 09:46:16AM -0500, Jay Pipes wrote:
> Are you proposing that an entity always be the owner of something?
I'm proposing every resources has an owner.
> If so, I dislike using the term "entity", since entity does not imply
> ownership. I'd prefer "owner" or "account", since t
Hi Eric, interesting proposal. Comments inline.
On Tue, Mar 1, 2011 at 9:14 PM, Eric Day wrote:
> 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 project
On Tue, Mar 1, 2011 at 7:46 PM, Monsyne Dragon wrote:
> On 3/1/11 6:32 PM, Justin Santa Barbara wrote:
> 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 '
On Wed, Mar 02, 2011 at 07:43:08PM +, Glen Campbell wrote:
> According to the proposed API 1.1 spec, it *does* use an extra element in
> the path to indicate the account; this is (presumably) returned by the
> auth system:
>
> http://servers.api.openstack.org/v1.1/1234/servers/12
>
> Where "1
According to the proposed API 1.1 spec, it *does* use an extra element in
the path to indicate the account; this is (presumably) returned by the
auth system:
http://servers.api.openstack.org/v1.1/1234/servers/12
Where "1234" is the account ID (actually a token, I believe) and "12" is
the server I
e more difficult. Also, some people
> like URLs to be readable and/or memorable.
>
>
> -----Original Message-
> From: "Eric Day"
> Sent: Tuesday, March 1, 2011 9:14pm
> To: "Justin Santa Barbara"
> Cc: openstack@lists.launchpad.net
> Subject:
quot;Justin Santa Barbara"
Cc: openstack@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
On Wed, Mar 02, 2011 at 05:07:04AM -0600, Michael Barton wrote:
> > Swift
> >
> > Swift has the concept of accounts, users, and groups. An account
> > contains users, and a user can belong to groups. Accounts names have an
> > abstraction layer, so while you may login with account "example.com",
>
> Swift
>
> Swift has the concept of accounts, users, and groups. An account
> contains users, and a user can belong to groups. Accounts names have an
> abstraction layer, so while you may login with account "example.com",
> the account name used within swift is a UUID with a prefix.
>
> By default
Eric,
I think that¹s an interesting proposal. I think I'll try to put something
together to visual this.
pvo
On 3/1/11 8:14 PM, "Eric Day" wrote:
>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
>
Thanks Eric. That actually makes a lot of sense to me, and seems to tally
with my understanding of the auth sequence for v1.0 and v1.1
and compatibility behavior for v1.0 as I described it.
I think my personal preference would be not to pass the project this way,
because it's another "special-cas
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
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
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
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 ac
On Tue, Mar 01, 2011 at 06:46:21PM -0600, Monsyne Dragon wrote:
> 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
>
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.
Won't putting this in the URL both:
1) Break CloudServers API compatibility (a total no-no)?
and
2) Preclude us from having e.g. multi-project queries (show me all my
servers in projects A and B)?
The options I see open to us are:
a) A cookie / header
b) A query parameter
c) Something in the requ
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
Hi everyone,
I'd like to build off the last auth thread about where the various
auth components are today and now look at what types of entities they
manage. Right now only Swift and Nova have entities, so only those
will be mentioned.
Swift
Swift has the concept of accounts, users, and groups.
20 matches
Mail list logo
