Sounds very LDAP.

Would it make sense to have a plug-in so we could mimic a pre-existing corp 
LDAP structure?


[] on behalf of 
Devin Carlen []
Sent: Thursday, February 03, 2011 4:02 PM
To: Monsyne Dragon
Subject: Re: [Openstack] Pondering multi-tenant needs in nova.

We were just talking about this the other day.  We definitely need some kind of 
further hierarchy.  I think a typical kind of use case for multi-tenant could 
be something like:

Enterprise contains Organizations

Organizations contain Organizations and Projects

Projects contain Instances, etc.

In this structure enterprise is just a top level organization.  If we structure 
it this way it would make metering and billing pretty simple.

On Feb 2, 2011, at 5:37 PM, Monsyne Dragon wrote:

I am sorting out some possible implementations for the multi-tenant-accounting 
blueprint, and the related system-usage-records bp,
and I just wanted to run this by anyone interested in such matters.

Basically, for multitenant purposes we need to introduce the concept of an 
'account' in nova, representing a customer,  that basically acts as a label for 
a group of resources (instances, etc), and for access control (i.e customer a 
cannot mess w/ customer b's stuff)

There was some confusion on how best to implement this, in relation to nova's 
project concept.  Projects are kind of like what we want an account to be, but 
there are some associations (like one project per network) which are not valid 
for our flat networking setup.  I am kind of straw-polling on which is better 

The options are:
1) Create a new 'account' concept in nova,  with an account basically being a 
subgroup of a project (providers would use a single, default project, with 
additional projects added if needed for separate brands, or resellers, etc), 
add in access control per account as well as project, and make sure apis/auth 
specify account appropriately,  have some way for a default account to used 
(per project) so account doesn't get in the way for non-multitenant users.

2) having account == nova's "project", and changing the network associations, 
etc so projects can support our model (as well as current models).  Support for 
associating accounts (projects) together for resellers, etc would either be 
delegated outside of nova or added later (it's not a current requirement).

In either case, accounts would be identified by name, which would  be an opaque 
string an outside system/person would assign, and could structure to their 
needs (ie. for associating accounts with common prefixes, etc)


   -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 
If you receive this transmission in error, please notify us immediately by 
at<>, and delete the original 
Your cooperation is appreciated.

Mailing list:
Post to     :<>
Unsubscribe :
More help   :

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to