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