[Openstack] [Merge] lp:~mdragon/nova/multi-tenant-accounting into lp:nova
mdragon at rackspace.com
Fri Mar 4 21:37:20 UTC 2011
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.
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 at rackspace.com, and delete the original message.
Your cooperation is appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openstack