openstack team mailing list archive

[Diego Parrilla Santamaría <diego.parrilla.santamaria@xxxxxxxxx>]

Sandy, Devin,

this is structure we had in my former cloud platform to fit easily in
a LDAP. It also helped in metering.

Diego

-
Diego Parrilla
nubeblog.com | nubeblog@xxxxxxxxxxxx | twitter.com/nubeblog
+34 649 94 43 29




On Thu, Feb 3, 2011 at 9:29 PM, Sandy Walsh <sandy.walsh@xxxxxxxxxxxxx> wrote:
> Sounds very LDAP.
> Would it make sense to have a plug-in so we could mimic a pre-existing corp
> LDAP structure?
> -S
>
> ________________________________
> From: openstack-bounces+sandy.walsh=rackspace.com@xxxxxxxxxxxxxxxxxxx
> [openstack-bounces+sandy.walsh=rackspace.com@xxxxxxxxxxxxxxxxxxx] on behalf
> of Devin Carlen [devin.carlen@xxxxxxxxx]
> Sent: Thursday, February 03, 2011 4:02 PM
> To: Monsyne Dragon
> 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
>
>