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 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 ab...@rackspace.com, and delete the original message. > Your cooperation is appreciated. > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
