[Openstack] Pondering multi-tenant needs in nova.

Sandy Walsh sandy.walsh at RACKSPACE.COM
Sun Feb 6 20:59:23 UTC 2011


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

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at 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 abuse at rackspace.com, and delete the original message. 
Your cooperation is appreciated.





More information about the Openstack mailing list