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