Re: [Openstack] [openstack][keystone] V3 API draft
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
[Openstack] [openstack][keystone] V3 API draft
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
Re: [Openstack] [openstack][keystone] V3 API draft
Great +1 all the points, specially tenants from user! Cheers! On Mon, May 21, 2012 at 6:11 PM, 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 -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ luis.gerv...@gmail.comwoorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
