← Back to team overview

openstack team mailing list archive

Fwd: Pondering multi-tenant needs in nova.

 

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 <bfschott@xxxxxxxxx>
> Date: February 6, 2011 6:09:02 PM EST
> To: Sandy Walsh <sandy.walsh@xxxxxxxxxxxxx>
> Cc: Jay Pipes <jaypipes@xxxxxxxxx>, John Purrier <john@xxxxxxxxxxxxx>, "openstack@xxxxxxxxxxxxxxxxxxx" <openstack@xxxxxxxxxxxxxxxxxxx>
> 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
> 

PNG image

> 
> 
> 
> 
> 
> Brian Schott
> bfschott@xxxxxxxxx
> 
> 
> 
> 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.com@xxxxxxxxxxxxxxxxxxx [openstack-bounces+sandy.walsh=rackspace.com@xxxxxxxxxxxxxxxxxxx] on behalf of Jay Pipes [jaypipes@xxxxxxxxx]
>> Sent: Sunday, February 06, 2011 10:57 AM
>> To: John Purrier
>> Cc: openstack@xxxxxxxxxxxxxxxxxxx
>> 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 <john@xxxxxxxxxxxxx> 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.org@xxxxxxxxxxxxxxxxxxx
>>> [mailto:openstack-bounces+john=openstack.org@xxxxxxxxxxxxxxxxxxx] On Behalf
>>> Of Glen Campbell
>>> Sent: Thursday, February 03, 2011 2:42 PM
>>> To: Devin Carlen; Monsyne Dragon
>>> Cc: openstack@xxxxxxxxxxxxxxxxxxx
>>> 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.carlen@xxxxxxxxx>
>>> Date: Thu, 3 Feb 2011 12:02:38 -0800
>>> To: Monsyne Dragon <mdragon@xxxxxxxxxxxxx>
>>> Cc: <openstack@xxxxxxxxxxxxxxxxxxx>
>>> 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 abuse@xxxxxxxxxxxxx, and delete the original message.
>>> Your cooperation is appreciated.
>>> 
>>> 
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>> 
>>> 
>>> 
>>> _______________________________________________ Mailing list:
>>> https://launchpad.net/~openstack Post to : openstack@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openstack More help :
>>> https://help.launchpad.net/ListHelp
>>> 
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>> 
>>> 
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> 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 abuse@xxxxxxxxxxxxx, and delete the original message. 
>> Your cooperation is appreciated.
>> 
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
> 


References