<!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 text="#000000" bgcolor="#ffffff">
On 3/4/11 2:13 PM, Justin Santa Barbara wrote:
<blockquote
cite="mid:AANLkTinGZ0bt1RKKpCnKJneBDNbJ1GnXzOORqH0FuEth@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div class="im">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<br>
</blockquote>
</div>
I think, really, we are getting off on a tangent here. The
purpose of multitenant is to have a label ('account' or
'project' or whatever.... ) that we tag resources (instances,
etc) in nova with so that we can group together usage reports,
etc, that go to some system outside of openstack for
reporting/billing/etc purpose.<br>
<br>
</blockquote>
<div><br>
</div>
<div>I think the purpose of "multitenant" is to support multiple
tenants :-) It's not clear to me that you can't do this
multi-tenant billing / reporting with what we have today -
without changing the URL, we know the user-id today (with our
'stub' auth). We'll likely know _more_ when "real-auth"
lands.</div>
</div>
</blockquote>
As for the url, I think we can wait for v1.1 and add it to the
spec, and just infer the account ('project') for v1.0 by assuming
that users are not members of more than 1 account. (pretty much as
eday suggested) <br>
<blockquote
cite="mid:AANLkTinGZ0bt1RKKpCnKJneBDNbJ1GnXzOORqH0FuEth@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>Can you explain what the proposed patch actually achieves?</div>
</div>
</blockquote>
We need to bill by account. (which is not user, tho' users are
linked to accounts) Also, we need report usages like "what
size/number of instances does account x have" so instances and other
such things need to be linked to the account. In nova the 'project'
already exists, and is basically what we need for this. The
instances, etc, belong to the project, and the users are linked to
it, so we can link billable actions by a user to a project. The
problem is that project is currently broken in the openstack api.
It's hardcoded to "openstack". This patch fixes that. Also, for
the purposes of development, testing, and small nova installs which
might use the current builtin auth, the info (accounts/users) for
that should be updatable via an admin api with a client like
novaclient. This patch adds that too. ("real" and/or large scale
nova installs would update this info through some external auth or
An Auth System To Be Named Later in nova, of course. )<br>
<br>
<blockquote
cite="mid:AANLkTinGZ0bt1RKKpCnKJneBDNbJ1GnXzOORqH0FuEth@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>I think maybe the problem is that the patches are "in the
wrong order" - I'm guessing you have a billing/reporting
solution and know that this is required, but you haven't
contributed it yet. Without that, we can't see the reason why
you were motivated to make this change. (This out-of-order
patching is something I'm very guilty of as well!)</div>
</div>
</blockquote>
The usages system (which is dependant on this) is described in the
system-usage-records blueprint in Launchpad. <br>
( <a class="moz-txt-link-freetext" href="https://blueprints.launchpad.net/nova/+spec/system-usage-records">https://blueprints.launchpad.net/nova/+spec/system-usage-records</a> )<br>
<br>
It has not been coded yet, since it is dependant on this multitenant
bp. It *is* scheduled, and approved for the cactus release, for
which merge-prop freeze is in ~2 weeks. <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>