| Thread Previous • Date Previous • Date Next • Thread Next |
On 3/4/11 11:53 AM, Eric Day wrote:
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.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.
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@xxxxxxxxxxxxx, and delete the original message.
Your cooperation is appreciated.
| Thread Previous • Date Previous • Date Next • Thread Next |
