[Openstack] [Merge] lp:~mdragon/nova/multi-tenant-accounting into lp:nova

Monsyne Dragon mdragon at rackspace.com
Tue Mar 8 20:00:32 UTC 2011

On 3/4/11 7:33 PM, Eric Day wrote:
> On Fri, Mar 04, 2011 at 01:35:48PM -0600, Monsyne Dragon 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.
>> 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.
> It's actually not, since the concept of 'project' (which you're mapping
> account on top of) is going away. Resources will have an owner, and
> these can be acted on by the owner or other accounts (or tenants)
> the owner gives permission to. So the account you're talking about
> is not just a label, it's going to be another tenant within the
> system. A deployment can treat tenants differently of course (ie,
> users, projects, billable accounts, ...).
I've read through termie & vish's authn/authz branch, and it appears 
that it does the same thing as this patch doing in this respect, namely 
it re-uses 'project' as the account/owner.  Again, all we really need, 
as far as the function of this blueprint is concerned, is a label we can 
slap on system usages.  The owner might eventually be an account with 
all sorts of acl's and delegations, etc, but for this functionality, we 
just need an identifier that will go on usage reports, i.e. 
'owner.name', so some external system can group them all together and do 
billing off them.

I have removed the piece of this branch that added the account to the 
service url. I agree that we can wait on that till auth is sorted out. 
(really, just removing the hardcoding of the account/project to 
"openstack" does the most in enabling us to start working on the 
system-usages blueprints.)

> I think the outstanding authn/authz branch needs to land (with some
> further work) before going to much further.
What is the timeline on that authn/authz branch looking like?  I'm  
assuming it won't be landing til' diablo.
> -Eric


     -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.

More information about the Openstack mailing list