I wanted to throw quotas out there for inclusion in the v3 API. In the format from the doc.<div><br></div><div><div>API Resources</div><div>Quota</div><div><ul><li>resource quotas associated with a tenant</li><li>a tenant may have 0 or more quotas</li>

</ul></div><div>resource attributes:</div><div><ul><li>name (unique per tenant)</li><li>value</li><li>id</li><li>url (fully qualified resource URL)</li></ul></div><div><br></div><div>V3 CORE API</div><div>Policy?</div><div>
<br></div><div>Quota</div>
<div><br></div><div><div>The key use cases we need to cover:</div><div><ul><li>CRUD for quotas</li></ul></div><div><div>(GET) /tenants/{tenant_id}/quotas ==> get_quotas</div><div>(GET) /tenants/{tenant_id}/quotas/{quota} ==> get_quota</div>
<div>(PUT) /tenants/{tenant_id}/quotas ==> create_or_replace_quotas</div><div>(DELETE) /tenants/{tenant_id}/quotas ==> delete_quotas</div><div><br></div><div>Quotas may be more applicable to an API extension but I wanted to put this out there for consideration.</div>
<div><br></div><div>Everett</div><div><br></div></div></div><div><div class="gmail_quote">On Mon, May 21, 2012 at 10:11 AM, Joseph Heck <span dir="ltr"><<a href="mailto:heckj@mac.com" target="_blank">heckj@mac.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Good morning,<br>
<br>
I wanted to announce that we have the first strawman/draft of a V3 API for Keystone available for comment and feedback. This is an early draft, and I expect there to be more than one.<br>
<br>
        <a href="https://docs.google.com/document/d/1s9C4EMxIZ55kZr62CKEC9ip7He_Q4_g1KRfSk9hY-Sg/edit" target="_blank">https://docs.google.com/document/d/1s9C4EMxIZ55kZr62CKEC9ip7He_Q4_g1KRfSk9hY-Sg/edit</a><br>
<br>
The general theme of this proposal is a broad CRUD based API supporting authentication and authorization needs in OpenStack. Back-end implementations of Keystone may not support all components of the API, hence an API return may be NotImplemented. This is to support Keystone as a programmatic facade to an deployment’s existing authentication and authorization system(s).<br>



Themes for changes:<br>
<br>
        • different style of pagination that I hope will be more effective for UI work<br>
        • consolidate CRUD operations currently in contrib into CORE<br>
        • adding a "url" resource attribute that's the fully qualified resource location for the keystone service<br>
        • flatten the service catalog structure<br>
        • added in a domains (collection of tenants)<br>
        • restructure role API calls to be specific to user->tenant or user->domain<br>
        • tokens are now very explicit to user+tenant combinations<br>
        • new API mechanisms to get tenants associated with a user<br>
        • generalized credentials associated with a user/tenant combo (ec2, pki, ssh keys, etc)<br>
        • propose an extended policy-implementation-specific API<br>
<br>
If you're interested, please review and provide feedback through the above Google Doc, or feel free to open broader discussion questions here on the list.<br>
<br>
-joe<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</blockquote></div><br></div>
</div>