Open Stack

Hey Guys,

Sorry to come into the conversation a bit late.

One of the reasons for having the tenatId in the URI is that it allows us to easily introspect what tenant a particular resource belongs to.  You can think of the tenant as literally a container for all of the resources that belong to that tenant.  How resources are organized into tenants (or containers or projects whatever you want to call them)  is up to the operator of the OpenStack service and for big deployments these organizations can be tied to rules and polices, so it becomes important that given a certain resource we can easily tell what tenant that resource belongs to.

If we are going to lose the tenant from the URI, we would need an alternative way of doing this introspection in a manner that is consistent between OpenStack APIs.  I'm not entirely married to keeping it in the tenant in the URI, but I certainly don't want to lose the ability to introspect it.

Thanks,

-jOrGe W.


On 05/08/2013 05:27 PM, Gabriel Hurley wrote:
> Proposal: The project/tenant ID should be dropped from the Nova v3 API URL structure.
> 
> Rationale: Removing it would simplify the requirements on the Keystone Service Catalog, it makes the future path for clients/consumers doing API version discovery better, and it makes the URLs significantly shorter, cleaner and more human-parseable.
> 
> The arguments in favor of including the project ID thus far have been twofold, both of which I will thusly invalidate:
> 
> 1. RESTfulness -- in purest REST the context of a request should not in any way alter the results returned by that endpoint. Thereby the argument was that we have to include the project ID in the URL in order to ensure that the "context" doesn't change the results. However, the project ID has not been the defining factor for what is returned by the RESTful URL for some time. We're actually using the AUTH TOKEN context to vary the response, so the entire argument is already faulty. That aside, the argument in favor of including the project ID in the URL to be "proper" is built on a somewhat dated notion of RESTfulness which many implementers (even within OpenStack) have chosen to eschew. I don't believe we gain anything by trying to adhere to this standard on principle when it offers no benefit.
> 
> 2. Caching -- a completely naïve cache would rely solely on the URL path to cache responses. As described above, this is already broken because two users with different roles may receive different responses on the same project ID. Any reasonable caching layer can cache based on a header, in this case Vary: X-Auth-Token.
> 
> If anyone has other arguments in favor of keeping the project ID in the URL I'd love to hear them, but otherwise I formally request that it be removed going forward.
> 
> All the best,
> 
>     - Gabriel