<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 2/3/11 2:02 PM, Devin Carlen wrote:
<blockquote cite="mid:225A399B-7C96-4EC4-8A41-1086CE19F51B@me.com"
type="cite">
<div><font class="Apple-style-span" face="'Courier New'">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:</font></div>
<div><font class="Apple-style-span" face="'Courier New'"><br>
</font></div>
<div><font class="Apple-style-span" face="'Courier New'">Enterprise
contains Organizations</font></div>
<div><font class="Apple-style-span" face="'Courier New'"><br>
</font></div>
<div><font class="Apple-style-span" face="'Courier New'">Organizations
contain Organizations and Projects</font></div>
<div><font class="Apple-style-span" face="'Courier New'"><br>
</font></div>
<div><font class="Apple-style-span" face="'Courier New'">Projects
contain Instances, etc.</font></div>
<div><font class="Apple-style-span" face="'Courier New'"><br>
</font></div>
<div><font class="Apple-style-span" face="'Courier New'"><br>
</font></div>
<div><font class="Apple-style-span" face="'Courier New'">In this
structure enterprise is just a top level organization. If we
structure it this way it would make metering and billing
pretty simple.</font></div>
</blockquote>
Yah, we are trying to avoid getting too deep into into
organizational structure with the multitenant stuff atm. At the
previous summit we were talking about using a pretty flat structure,
basically 'accounts' for grouping instances, with a flexible naming
scheme, and leave the hierarchy management as being something
outside the scope of Nova, which would be taken care of by other
systems (since each nova implementer is likely to have very
different needs and ideas on how to do that. ). Since the account
names would be opaque strings to Nova, if an outside system wanted
to use account names like "JoeCorp:usdivision:hr:recruiting" it
could. <br>
<br>
The main decision we are making here is, do we implement accounts as
projects (in which case we need to make projects able to share
networks to support our model) or do we add a new account concept
(in which case, Rackspace, and others using similar org models, will
pretty much ignore the "project" concept, just using a single
'default' project). <br>
<font face="'Courier New'"><br>
<br>
<br>
<br>
</font>
<blockquote cite="mid:225A399B-7C96-4EC4-8A41-1086CE19F51B@me.com"
type="cite">
<div>
<div>On Feb 2, 2011, at 5:37 PM, Monsyne Dragon wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div>I am sorting out some possible implementations for the
multi-tenant-accounting blueprint, and the related
system-usage-records bp,<br>
and I just wanted to run this by anyone interested in such
matters.<br>
<br>
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)<br>
<br>
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:<br>
<br>
The options are:<br>
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.<br>
<br>
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).<br>
<br>
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)<br>
<br>
-- <br>
<br>
--<br>
-Monsyne Dragon<br>
work: 210-312-4190<br>
mobile 210-441-0965<br>
google voice: 210-338-0336<br>
<br>
<br>
<br>
Confidentiality Notice: This e-mail message (including any
attached or<br>
embedded documents) is intended for the exclusive and
confidential use of the<br>
individual or entity to which this message is addressed, and
unless otherwise<br>
expressly indicated, is confidential and privileged
information of Rackspace.<br>
Any dissemination, distribution or copying of the enclosed
material is prohibited.<br>
If you receive this transmission in error, please notify us
immediately by e-mail<br>
at <a moz-do-not-send="true"
href="mailto:abuse@rackspace.com">abuse@rackspace.com</a>,
and delete the original message.<br>
Your cooperation is appreciated.<br>
<br>
<br>
_______________________________________________<br>
Mailing list: <a moz-do-not-send="true"
href="https://launchpad.net/%7Eopenstack">https://launchpad.net/~openstack</a><br>
Post to : <a moz-do-not-send="true"
href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a moz-do-not-send="true"
href="https://launchpad.net/%7Eopenstack">https://launchpad.net/~openstack</a><br>
More help : <a moz-do-not-send="true"
href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><br>
</div>
</blockquote>
</div>
<br>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
--
-Monsyne Dragon
work: 210-312-4190
mobile 210-441-0965
google voice: 210-338-0336</pre>
<PRE>
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@rackspace.com, and delete the original message.
Your cooperation is appreciated.
</PRE></body>
</html>