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 <mdra...@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 <mdra...@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 ab...@rackspace.com, and delete the original message. >> Your cooperation is appreciated. >> >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@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 ab...@rackspace.com, and delete the original message. > Your cooperation is appreciated. > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
