openstack team mailing list archive
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:
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)
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.
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. )
Can you explain what the proposed patch actually achieves?
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.
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.