Hi Monsyne, it's a very interesting topic and I'm curious about the reason why you are using the Flat Networking set up. From the conversations in other threads it seems the Service Providers prefer different networking approaches: VLAN oriented basically.
Regards Diego - Diego Parrilla nubeblog.com | [email protected] | twitter.com/nubeblog +34 649 94 43 29 On Thu, Feb 3, 2011 at 2:37 AM, Monsyne Dragon <[email protected]> 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 [email protected], and delete the original message. > Your cooperation is appreciated. > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
