openstack team mailing list archive

[Everett Toews <everett.toews@xxxxxxxxx>]

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 <heckj@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>