Ah, was member of Nova team, but not OpenStack team. I think this is still relevant to the discussion. I've read here that accounts are a 1) collection of projects, or 2) a collection of users, or 3) a billing / audit tag on usage reports and/or logs. The blueprint seems to indicate that the functionality of projects is what is required. So what is the limitation?
Begin forwarded message: > From: Brian Schott <bfsch...@gmail.com> > Date: February 6, 2011 6:09:02 PM EST > To: Sandy Walsh <sandy.wa...@rackspace.com> > Cc: Jay Pipes <jaypi...@gmail.com>, John Purrier <j...@openstack.org>, > "openstack@lists.launchpad.net" <openstack@lists.launchpad.net> > Subject: Re: [Openstack] Pondering multi-tenant needs in nova. > > Going back to the original question, it seems that projects has all of the > necessary authentication, quota, audit hooks, and role-based management of > granting users access to projects to support multi-tennant management, but > the issue is that you can't have multiple projects in a flat network? > > If you create an accounts (opaque string or some arbitrary data structure > doesn't matter) don't you have to create all of the same quota/role > functionality as projects without the network? Or is this just an opaque > filter on all of these table views? > > Or are we talking about Accounts as a box to the LEFT of Users that groups > multiple users into a single billing domain? > > http://nova.openstack.org/adminguide/managing.projects.html >
<<inline: graphviz-54ff97bd95e52a8aeb5853f52508db83ec26fb2e.png>>
> > > > > > Brian Schott > bfsch...@gmail.com > > > > On Feb 6, 2011, at 3:59 PM, Sandy Walsh wrote: > >> I think, but I'm not sure, that Glen is suggesting to just keep a URI for >> the enterprise element. This might map to a database, LDAP, etc. and it >> might be internal to Nova or external (likely). >> >> One plug-in for tentant structure might from a database, in which your >> proposal would be perfect (parsing the key as the tree to fetch). But >> another could be LDAP, where you would ask it for the >> parents/siblings/children. >> >> The plugin interface: Who is my parent? Who are my children? Can Customer A >> see Customer B? Who are the clients of Reseller X? Who do I bill? Where does >> the audit log come from? ... this seems to be where the real magic has to >> happen. >> >> Unless I missed something? >> >> -Sandy >> >> >> ________________________________________ >> From: openstack-bounces+sandy.walsh=rackspace....@lists.launchpad.net >> [openstack-bounces+sandy.walsh=rackspace....@lists.launchpad.net] on behalf >> of Jay Pipes [jaypi...@gmail.com] >> Sent: Sunday, February 06, 2011 10:57 AM >> To: John Purrier >> Cc: openstack@lists.launchpad.net >> Subject: Re: [Openstack] Pondering multi-tenant needs in nova. >> >> Strongly disagree, but nicely, of course :) >> >> I'll disagree by showing you an example of why not having a queryable >> org model is problematic: >> >> Let's say we go ahead and do what Glen suggests and have a string >> account ID that is then attached to the user in a one to many >> relationship. >> >> In SQL (MySQL variant below), this is represented as so: >> >> # Our existing users table: >> CREATE TABLE users ( >> id VARCHAR(255) NOT NULL PRIMARY KEY, >> access_key VARCHAR(255) NOT NULL, >> secret_key VARCHAR(255) NOT NULL, >> is_admin TINYINT NOT NULL DEFAULT 0 >> ); >> >> # Proposed accounts table, with string based tag-like account identifier: >> CREATE TABLE accounts ( >> id VARCHAR(255) NOT NULL PRIMARY KEY, >> user_id VARCHAR(255) NOT NULL, >> FOREIGN KEY fk_users (user_id) REFERENCES users (id) >> ); >> >> Now let's say that we store account IDs like this: enterprise-dept-milestone. >> >> How would we get all accounts in Enterprise X? Easy, and efficiently: >> >> SELECT id FROM accounts WHERE id LIKE "X%" >> >> How would we get all accounts in Enterprise X and Dept Y? Again, it >> would be easy and efficient: >> >> SELECT id FROM accounts WHERE id LIKE "X-Y-%" >> >> But, what happens if multiple departments can work on the same >> milestone (a common requirement)? >> >> How do we query for all accounts in Enterprise X and Milestone Z? >> >> The SQL would be horrific, and with millions of records, would bog the >> reporting system down (trust me): >> >> SELECT id FROM accounts WHERE id LIKE "X%-%-%Z". >> >> The above query would force a full table scan across the entire >> accounts table. An organization like Rackspace would theoretically >> have millions of account records (# customers + (# customers X >> #customer "projects") + (# resellers X # reseller customers) + (# >> reseller customers X # reseller customer "projects")) >> >> The "simpler" query of getting all accounts working on a milestone now >> becomes equally inefficient: >> >> SELECT id FROM accounts WHERE if LIKE "%-Z" >> >> The above query also has the side-effect of introducing subtle bugs >> when, and this will happen because of Murphy's law, accounts called >> "Rackspace-Accounting" and "Rackspace-IT-Accounting" are created. >> Now, the account for the accounting department and the IT department's >> "Accounting" milestone are erroneously returned. >> >> While it may seem nice and easy to put string-based, loose tags into >> the system, this decision is extremely difficult to reverse when made, >> and it leads to inefficiencies in the querying of the system and >> subtle query bugs as noted above. >> >> A more robust way of structuring the schema is like so, again in the >> MySQL SQL variant: >> >> # Our existing users table: >> CREATE TABLE users ( >> id VARCHAR(255) NOT NULL PRIMARY KEY, >> access_key VARCHAR(255) NOT NULL, >> secret_key VARCHAR(255) NOT NULL, >> is_admin TINYINT NOT NULL DEFAULT 0 >> ); >> >> # Organizations are collections of users that can contain other organizations >> CREATE TABLE organization ( >> id INT NOT NULL NOT NULL PRIMARY KEY, >> user_id VARCHAR(255) NOT NULL, >> parent INT NULL, # Adjacency list model enables efficient child and >> parent lookups >> left INT NULL, # left and right enable the nested sets model that enables >> right INT NULL, # equally efficient lookups of more complex relationships >> FOREIGN KEY fk_users (user_id) REFERENCES users (id) >> ); >> >> The above structure can accomodate both simple (get my immediate >> parent or immediate children) queries and complex queries (get ALL my >> children, aggregate querying across the entire tree or subtrees) and >> do so efficiently. The query API interface that we expose via Nova >> (that would be consumed by some reporting/audit/management tools) >> would therefore not be a serious drain on the databases storing Nova >> data. >> >> More information on the adjacency list and nested sets models are >> available here: >> >> http://en.wikipedia.org/wiki/Nested_set_model >> http://en.wikipedia.org/wiki/Adjacency_list_model >> >> I'd highly recommend this solution as opposed to the seemingly simple >> tag-based solution that leads to gross querying inefficiencies and >> subtle bugs. >> >> Just my two cents. >> >> -jay >> >> On Thu, Feb 3, 2011 at 7:38 PM, John Purrier <j...@openstack.org> wrote: >>> I think Glen is on the right track here. Having the account_ID be a string >>> with no connotation for Nova allows two benefits: 1) deployments can create >>> the arbitrary organizational models that fit their particular DC, physical, >>> and logical structures, and 2) the Nova code is simpler as the hierarchical >>> concepts do not have any manifestations in the code. >>> >>> >>> >>> Additional benefit includes an easier mapping to the particular identity and >>> authorization system that a deployment chooses to use. >>> >>> >>> >>> John >>> >>> >>> >>> From: openstack-bounces+john=openstack....@lists.launchpad.net >>> [mailto:openstack-bounces+john=openstack....@lists.launchpad.net] On Behalf >>> Of Glen Campbell >>> Sent: Thursday, February 03, 2011 2:42 PM >>> To: Devin Carlen; Monsyne Dragon >>> Cc: openstack@lists.launchpad.net >>> Subject: Re: [Openstack] Pondering multi-tenant needs in nova. >>> >>> >>> >>> I think that this could be done in the current proposal. Specifically, the >>> account_id is an arbitrary string that is generated externally to Nova. You >>> could, for example, easily identify an organizational hierarchy. For >>> example, an accountID could be: >>> >>> >>> >>> enterprise-org-project-milestone >>> >>> >>> >>> From Nova's point of view, it makes no difference, so long as that string is >>> associated with a usage event and regurgitated when reported. The cloud >>> administrator can interpret it however it chooses. For simple organizations, >>> it could be identical to the project_id, or even just blank. The project_id >>> holds the network information, and the account_id tracks the usage and other >>> notifications. >>> >>> >>> >>> There's no good reason for Nova to have to model an organization internally; >>> it certainly wouldn't match all the possible org structures available. >>> >>> >>> >>> >>> >>> >>> >>> From: Devin Carlen <devin.car...@gmail.com> >>> Date: Thu, 3 Feb 2011 12:02:38 -0800 >>> To: Monsyne Dragon <mdra...@rackspace.com> >>> Cc: <openstack@lists.launchpad.net> >>> 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 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 >>> >>> _______________________________________________ >>> 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 >> >> >> 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
