Open Stack

How about this:  instruct clients to simply use the URL that they see in the Keystone catalog and append resources to that.  The Operator decides whether or not that endpoint contains a tenant id.  The client shouldn't care whether the tenant id is there or not.

-jOrGe W.


On Nov 2, 2012, at 5:58 PM, Vishvananda Ishaya wrote:

> 
> On Nov 2, 2012, at 1:59 AM, Salvatore Orlando <sorlando at nicira.com> wrote:
> 
>> I agree with Eugene that the tenant_id is not necessary in the URI.
>> Euguene also has a good point on shared resources - and on this note I would like to remark that at the moment we have a very simple sharing model in Quantum. The model is that a network can either be shared with everybody or stay private. We are aware that this is fairly trivial, but suited Quantum needs for the Folsom release. If we find out we need to improve this mechanism, we'll do it - as long as keep the API backward compatible!
>> 
>> I believe that Peter's initial note was about consistency across all openstack projects. Dan provided probably the most reasonable explanation for this - I tried to provide similar reasons in another thread but that was more of a guess as I wasn't very active on the project at the time (yeah, that a lame excuse... I know).
>> 
>> From a user perspective we understand that consistency across APIs for different projects is very important. As user I would be at least perplexed by this difference.
>> On the other hand, reintroducing the tenant_id in the URI structure and thus 'uniforming' to other Openstack projects, would likely represent a backward incompatible change for our API, and then is a very delicate decision to take.
>> 
>> Salvatore
> 
> FWIW i think tenant_id in the uri is useless and I will be proposing to remove it in the next version of the nova api. Glance doesn't have it either.
> 
> Vish
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev