I wanted to throw quotas out there for inclusion in the v3 API. In the format from the doc.
API Resources Quota - resource quotas associated with a tenant - a tenant may have 0 or more quotas resource attributes: - name (unique per tenant) - value - id - url (fully qualified resource URL) V3 CORE API Policy? Quota The key use cases we need to cover: - CRUD for quotas (GET) /tenants/{tenant_id}/quotas ==> get_quotas (GET) /tenants/{tenant_id}/quotas/{quota} ==> get_quota (PUT) /tenants/{tenant_id}/quotas ==> create_or_replace_quotas (DELETE) /tenants/{tenant_id}/quotas ==> delete_quotas Quotas may be more applicable to an API extension but I wanted to put this out there for consideration. Everett On Mon, May 21, 2012 at 10:11 AM, Joseph Heck <he...@mac.com> wrote: > Good morning, > > 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. > > > https://docs.google.com/document/d/1s9C4EMxIZ55kZr62CKEC9ip7He_Q4_g1KRfSk9hY-Sg/edit > > 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). > Themes for changes: > > • different style of pagination that I hope will be more effective > for UI work > • consolidate CRUD operations currently in contrib into CORE > • adding a "url" resource attribute that's the fully qualified > resource location for the keystone service > • flatten the service catalog structure > • added in a domains (collection of tenants) > • restructure role API calls to be specific to user->tenant or > user->domain > • tokens are now very explicit to user+tenant combinations > • new API mechanisms to get tenants associated with a user > • generalized credentials associated with a user/tenant combo (ec2, > pki, ssh keys, etc) > • propose an extended policy-implementation-specific API > > 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. > > -joe > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp