openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #00590
Re: Pondering multi-tenant needs in nova.
In general the networking model is very disconnected between various
parts of the community. We are at a point that a consensus needs to be
reached. The decision of how VLANs relate to network segments, the size
of each, how many you can have per account/project.. All of this is very
grey and uncleanly decided atm. We have distinct networking proposals
from at least three major companies being released in next week or so..
I highly recommend we all focus our attentions there so that items like
this can actually be defined on a factual foundation rather then guessed
outcome of final networking model and how it relates to users, account
and projects. .
Aimon
On 2/7/11 9:20 AM, Monsyne Dragon wrote:
> On 2/6/11 5:09 PM, Brian Schott wrote:
>> 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?
>>
> Yup. that is the jist of it. Projects seem to have all of the
> 'account-y' features we need, the only issue being that the current db
> model assumes 1 network per project, which is not valid for a
> flat-network model. This is probably just an artifact of the fact
> that the vlan model was created first, so that assumption crept in to
> the project model. It's easy enough to fix, however. We can make
> project <-> network a many to many relationship, which will allow our
> flat model, and also the current vlan models as well. (we have to
> change this model a bit anyway. We need to allow multiple netwoks per
> project, as well, since rackspace assigns private 'service-net'
> networks to instances as well as the public internet. That is part of
> the multi-nic bp)
>
> As far as the org model stuff goes, I thought the discussion at the
> last summit was that that sort of thing was outside of the scope of
> Nova, and we would just leave it to other systems. (i.e. a provider's
> billing system would know the relationships between accounts, and roll
> things up accordingly as it pulls usage data from nova (via some kind
> of pubsub interface) )
>
>
>> 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
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>
>
> --
>
> --
> -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
--
Aimon Bustardo | Morph Labs | +1.310.625.0608 (mobile) | +1.310.437.4898 (office) | www.morphlabs.com | aimon@xxxxxx
References
