openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #00473
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
>
>
>
>
>
>
> 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
