<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div text="#000000" bgcolor="#ffffff">The usages system (which is dependant on this) ... 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. </div>
</blockquote><div><br></div><div>Ouch. Even though it's approved though, my understanding is that we're not obligated to deliver it, because we're doing time-based releases, not feature-based releases ? (And that is a question - any PM types want to chip in here?)</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div text="#000000" bgcolor="#ffffff">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></div></blockquote><div><br></div><div>I think that may be the way to go given the deadline.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div text="#000000" bgcolor="#ffffff"><div class="im">
<blockquote type="cite">
<div class="gmail_quote">
<div>Can you explain what the proposed patch actually achieves?</div>
</div>
</blockquote></div>
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. )</div></blockquote><div><br></div><div>I think these are all great features and are all needed, but passing the project in the URL is controversial. I think your patch would be much simpler if you split it into 2 - passing the project "somehow", and the other stuff. I think the second should be uncontroversial, I think there's a lot of debate on how to do the first. Then we can really focus on the core of the controversial bit, and you may be unblocked from developing the usages system. I don't see the first one getting resolved until the "Project Technical Lead" for nova is appointed, but that's just my opinion.</div>
<div><br></div><div>In terms of nomenclature, I think we should stop calling things "accounts" if we mean "project" and not "user". I'm hopelessly confused by that :-)</div><div> </div></div>