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