openstack team mailing list archive

["John Purrier" <john@xxxxxxxxxxxxx>]

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