<meta http-equiv="content-type" content="text/html; charset=utf-8"><div>Here's how I understand it. Suppose my username is justin and I'm a member of 3 projects: project1, project2 and project3</div><div><ol><li>If I log in using the v1.0 API, I hit <a href="http://auth.openstack.org/v1.0">auth.openstack.org/v1.0</a> and I get X-Server-Management-Url: <a href="http://nova.openstack.org/v1.0/justin">nova.openstack.org/v1.0/justin</a>.</li>
<li>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 <a href="http://nova.openstack.org/v1.0/justin/servers">nova.openstack.org/v1.0/justin/servers</a>)</li>
<li>If I log in using the v1.1 API, I hit <a href="http://auth.openstack.org/v1.1">auth.openstack.org/v1.1</a> and I get X-ServerManagement-Url: <a href="http://nova.openstack.org/v1.1">nova.openstack.org/v1.1</a> </li><li>
If I want to query across everything, I append my username to the URL, v1.0 style: <a href="http://nova.openstack.org/v1.1/justinsb">nova.openstack.org/v1.1/justinsb</a> and get the list of all servers hitting <a href="http://nova.openstack.org/v1.1/justin/servers">nova.openstack.org/v1.1/justin/servers</a></li>
<li>If I want to see the servers only in project1, I append my project name to the URL, so I'd hit <a href="http://nova.openstack.org/v1.1/project1/servers">nova.openstack.org/v1.1/project1/servers</a></li></ol></div>
<div>Is my understanding correct?</div><div><br></div><div>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: <a href="http://nova.openstack.org/v1.1/project1+project2/servers">nova.openstack.org/v1.1/project1+project2/servers</a>.</div>
<div><br></div><div>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.<br>
<br></div><div>Justin<br><br><div class="gmail_quote">On Tue, Mar 1, 2011 at 4:46 PM, Monsyne Dragon <span dir="ltr"><<a href="mailto:mdragon@rackspace.com">mdragon@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div text="#000000" bgcolor="#ffffff"><div class="im">
On 3/1/11 6:32 PM, Justin Santa Barbara wrote:
<blockquote type="cite">Won't putting this in the URL both:
<div><br>
</div>
<div>1) Break CloudServers API compatibility (a total no-no)?</div>
<div>and</div>
</blockquote></div>
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. <br>
(i.e. when you auth and get a token back, the server management url
returned looks like:
<a href="http://www.example.org/v1.0/" target="_blank">http://www.example.org/v1.0/</a><accountidentifier>/ the
openstack api urls are defined as hanging off of that. ) <br><div class="im">
<br>
<blockquote type="cite">
<div>2) Preclude us from having e.g. multi-project queries (show
me all my servers in projects A and B)?</div>
</blockquote></div>
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. <br>
. <br><div class="im">
<br>
<blockquote type="cite">
<div>
<div>The options I see open to us are:</div>
<div>a) A cookie / header</div>
<div>b) A query parameter</div>
<div>c) Something in the request body</div>
<div><br>
</div>
<div>I like (c) because it's the least hacky and is not tied to
HTTP.</div>
<div><br>
</div>
</div>
</blockquote></div>
Really it's not that hacky. it's basically just nested REST
resources. <br><div><div></div><div class="h5">
<br>
<blockquote type="cite">
<div>
<div>Justin<br>
<br>
<br>
<br>
<br>
<br>
<div class="gmail_quote">On Tue, Mar 1, 2011 at 4:23 PM,
Monsyne Dragon <span dir="ltr"><<a href="mailto:mdragon@rackspace.com" target="_blank">mdragon@rackspace.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
On 3/1/11 6:11 PM, Eric Day wrote:<br>
<br>
[ ... trimmed ... ]
<div><br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
For the OpenStack API, we need something a bit
different from what we<br>
have today. We currently have no way of passing in a
project name,<br>
so I propose we add an "entity" element to the path
name (just like<br>
Swift does). For example, instead of
"/v1.0/servers/1", it would be<br>
"/v1.0/entity/servers/1", where entity can represent
an account (like<br>
swift), project (like current nova), or even a user
entity (deployments<br>
where projects or accounts are not used). Our window
for OpenStack<br>
API changes is still open as it's still under heavy
development,<br>
and I think this path addition will provide more
functionality and<br>
a consistent structure across services (glance and
burrow will be<br>
using an account or "entity" in the path as well).<br>
</blockquote>
</div>
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.<br>
<br>
-- <br>
<br>
--<br>
-Monsyne Dragon<br>
work: 210-312-4190<br>
mobile 210-441-0965<br>
google voice: 210-338-0336<br>
<br>
<br>
<br>
Confidentiality Notice: This e-mail message (including any
attached or<br>
embedded documents) is intended for the exclusive and
confidential use of the<br>
individual or entity to which this message is addressed,
and unless otherwise<br>
expressly indicated, is confidential and privileged
information of Rackspace.<br>
Any dissemination, distribution or copying of the enclosed
material is prohibited.<br>
If you receive this transmission in error, please notify
us immediately by e-mail<br>
at <a href="mailto:abuse@rackspace.com" target="_blank">abuse@rackspace.com</a>,
and delete the original message.<br>
Your cooperation is appreciated.
<div>
<div><br>
<br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
<br>
<pre cols="72">--
--
-Monsyne Dragon
work: 210-312-4190
mobile 210-441-0965
google voice: 210-338-0336</pre>
<pre>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 <a href="mailto:abuse@rackspace.com" target="_blank">abuse@rackspace.com</a>, and delete the original message.
Your cooperation is appreciated.
</pre></div></div></div>
</blockquote></div><br></div>