openstack team mailing list archive

[Monsyne Dragon <mdragon@xxxxxxxxxxxxx>]

On 2/3/11 2:02 PM, Devin Carlen wrote:
> 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.
Yah, we are trying to avoid getting  too deep into into organizational 
structure with the multitenant stuff atm.  At the previous summit we 
were talking about using a pretty flat structure, basically 'accounts' 
for grouping instances, with a flexible naming scheme, and leave the 
hierarchy management as being something outside the scope of Nova, which 
would be taken care of by other systems (since each nova implementer is 
likely to have very different needs and ideas on how to do that. ).  
Since the account names would be opaque strings to Nova, if an outside 
system wanted to use account names like  
"JoeCorp:usdivision:hr:recruiting" it could.

The main decision we are making here is, do we implement accounts as 
projects (in which case we need to make projects able to share networks 
to support our model) or do we add a new account concept (in which case, 
Rackspace, and others using similar org models, will pretty much ignore 
the "project"  concept, just using a single 'default' project).




> 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 here:
> >
> > 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 prohibited.
> > If you receive this transmission in error, please notify us 
> > immediately by e-mail
> > at abuse@xxxxxxxxxxxxx <mailto:abuse@xxxxxxxxxxxxx>, and delete the 
> > original message.
> > Your cooperation is appreciated.
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack 
> > <https://launchpad.net/%7Eopenstack>
> > Post to     : openstack@xxxxxxxxxxxxxxxxxxx 
> > <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
> > Unsubscribe : https://launchpad.net/~openstack 
> > <https://launchpad.net/%7Eopenstack>
> > More help   : https://help.launchpad.net/ListHelp


--

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