openstack team mailing list archive

[Monsyne Dragon <mdragon@xxxxxxxxxxxxx>]

On 3/4/11 2:13 PM, Justin Santa Barbara wrote:
>     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.
>
>
> 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.
 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)
> Can you explain what the proposed patch actually achieves?
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. )

> 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!)
The usages system (which is dependant on this) is described in the 
system-usage-records blueprint in Launchpad.
( https://blueprints.launchpad.net/nova/+spec/system-usage-records )

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.

--

--
    -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.