openstack team mailing list archive

[Brian Schott <bfschott@xxxxxxxxx>]

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