← Back to team overview

openstack team mailing list archive

Re: [Merge] lp:~mdragon/nova/multi-tenant-accounting into lp:nova


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.

Follow ups