Open Stack

On 3/4/11 11:53 AM, Eric Day wrote:
> On Thu, Mar 03, 2011 at 06:36:14PM -0600, Monsyne Dragon wrote:
>> On 3/3/11 5:51 PM, Eric Day wrote:
>>> Getting into this a bit more, I'm not sure this is something that
>>> should be the default. For CloudServers v1.0 token auth compatibility,
>>> I'm not even sure this is the best path. It seems like this is
>>> something that should be handled at the service level with the
>>> API version, not by the token server. For v1.0, account=user from
>>> token. For v1.1, just look at the path element for account.
>> sorry, a bit confused...   "I'm not even sure this is the best
>> path"...  'this' == ?  (mental buffer overflow here...)
> This == putting the account in the service URL during token
> auth. Rather than return:
>
> https://nova.openstack.org/v1.1/<account_id>
>
> for old clients, it seems returning:
>
> https://nova.openstack.org/v1.0/
>
> makes more sense. The v1.0 handler would then not look for account_id
> in the path and simply set account=token user. In other words, there
> is more than one way to fix this, via base URLs or API versioning. It
> seems like a better fit for API versioning than service URLs.
>
I think, really, we are getting off on a tangent here. The purpose of 
multitenant is to have a label ('account' or 'project' or whatever.... ) 
that we tag resources (instances, etc) in nova with so that we can group 
together usage reports, etc, that go to some system outside of openstack 
for reporting/billing/etc purpose.

The whole thing is pretty tangential to auth.  for multitenant, we 
really don't care how the user logs in, or where the account label comes 
from.  Just that it's there, so when someone takes a billable action, we 
can record it under the right label for billing, and if an entity, like 
an instance, exists we can count it under such a label for the same.

The only things i did with auth was make sure the existing builtin auth 
in nova can pass through that label (knowing that most 'real' nova 
installs will not use the builtin auth anyway. They will use an external 
system. ) and make the api pick up that info.  If that gets torn out to 
provide a better builtin auth, that's fine.  Also, the same for the 
admin api's. If they get shuffled off to some better auth system's api, 
that's fine. We are just using them to say 'this account-label exists. 
attatch stuff to it' , we are not doing authorization .

As for the account_id in the urls...  Hmm... Having it specc'ed in v1.1 
is definitely good.  For v1.0, we can just pull the account from the 
token user, as long as the user is a member of only one account (the 
code to do that is actually in there, where it generates the service 
url).  I suppose that is not a pressing use case (and eventualy  could 
be answered with "user the v1.1 api). This would prevent any kind of 
proxy caching on the v1.0 api, but I'm not sure if that is important (is 
broken in nova atm, since things like GET /v1.0/servers return differently)


-- 

--
     -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 abuse at rackspace.com, and delete the original message.
Your cooperation is appreciated.