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.<div><br></div><div>I think my personal preference would be not to pass the project this way, because it's another "special-case" way of passing parameters (I don't dare mention the Metadata word), and it's also one we can't use consistently (e.g. cross-project search). But the horse has already bolted on this one, so it's just a preference.</div>
<div><br></div><div>Do we know if CloudServers had a strong reason for doing things this way? (Caching? Session affinity?)</div><div><br></div><div>Justin</div><div><div><br><br>
<br><br><div class="gmail_quote">On Tue, Mar 1, 2011 at 6:14 PM, Eric Day <span dir="ltr"><<a href="mailto:eday@oddments.org">eday@oddments.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
For that query you would, but not all. If you want to create a new<br>
instance for project1 you would:<br>
<br>
<a href="http://nova.openstack.org/v1.1/project1/servers" target="_blank">nova.openstack.org/v1.1/project1/servers</a><br>
<br>
Or if you wanted to reboot instance X in project1:<br>
<br>
<a href="http://nova.openstack.org/v1.1/project1/servers/X" target="_blank">nova.openstack.org/v1.1/project1/servers/X</a><br>
<br>
Note that the following resource is not the same as the last, since<br>
justin wouldn't be the owner for instance X, project1 would be:<br>
<br>
<a href="http://nova.openstack.org/v1.1/justin/servers/X" target="_blank">nova.openstack.org/v1.1/justin/servers/X</a><br>
<br>
I think searches will always have special cases with filter options,<br>
but for identifying a canonical URL for a resource, having the entity<br>
name of the owner in there seems correct.<br>
<br>
The main thing I'm trying to figure out is whether to use an extra<br>
entity in the path for new service URLs. Swift does and Nova does not,<br>
and it would be nice to have some consistency. I see the benefits of<br>
both, and in Swift's case it needs to for simple public URLs (where<br>
there is no user context).<br>
<font color="#888888"><br>
-Eric<br>
</font><div><div></div><div class="h5"><br>
On Tue, Mar 01, 2011 at 06:00:12PM -0800, Justin Santa Barbara wrote:<br>
> If we're always going to pass the same user-id token (for a particular<br>
> user), what's the value in passing it at all? Why not get it from the<br>
> authentication token?<br>
> e.g. my X-Auth-Token could look like: "justinsb<br>
> project1,project2,project3 5OPr9UR2xk32K9ArAjO562e" (i.e. my username,<br>
> projects and a crypto signature)<br>
> Justin<br>
><br>
> On Tue, Mar 1, 2011 at 5:51 PM, Eric Day <<a href="mailto:eday@oddments.org">eday@oddments.org</a>> wrote:<br>
><br>
> Hi Justin,<br>
> On Tue, Mar 01, 2011 at 05:14:42PM -0800, Justin Santa Barbara wrote:<br>
> > However, what I don't understand is how I can query my servers in<br>
> project1<br>
> > and project2 (but not those in project3). *The only way I could see<br>
> is<br>
> > doing something like this:<br>
> > *<a href="http://nova.openstack.org/v1.1/project1+project2/servers" target="_blank">nova.openstack.org/v1.1/project1+project2/servers</a>.<br>
> > I agree that REST paths aren't themselves hacky in the<br>
> single-project<br>
> > case, but I don't yet grok the multi-project query. *Of the 3<br>
> options I do<br>
> > grok, I see (c) as the least hacky.<br>
><br>
> I would probably say use <a href="http://nova.openstack.org/v1.1/justin/servers" target="_blank">nova.openstack.org/v1.1/justin/servers</a> with<br>
> one or more filter parameters in the URL or body as you mention. This<br>
> something to consider across all services, not just nova. AFAIK<br>
> Swift doesn't support queries across multiple accounts right now,<br>
> so I'd like to hear their thoughts on it as well.<br>
> -Eric<br>
</div></div></blockquote></div><br></div></div>