Hi Eric, interesting proposal. Comments inline.
On Tue, Mar 1, 2011 at 9:14 PM, Eric Day e...@oddments.org 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
On Tue, Mar 1, 2011 at 7:46 PM, Monsyne Dragon mdra...@rackspace.com 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.
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, a user
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,
the account
jus...@fathomdb.com
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 project1
Santa Barbara jus...@fathomdb.com
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
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 ID.
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 1234 is
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
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
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:
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
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 e...@oddments.org wrote:
For that query you would, but not all. If you want to create a new
instance for project1 you would:
13 matches
Mail list logo
