Hi Joe, I added lots of comments on the google doc. I think most of them reinforce the existing design decisions. That said, there are a few high-level issues I'd like to ask for discussion on:
1. This API features no differentiation between the "admin" API and the regular API as it exists currently; I assume this is due to the new policy engine. Am I correct, and does that mean that Keystone will no longer be using the admin port (35357)? 2. User roles on domains solves the issue of "who has the power to manage tenants", but that then begs the question "who has the power to manage domains?" The same question applies to services and policies. Anything that is not scoped to the domain still falls into a grey area, and the previous answer of "anyone who's got that permission anywhere has that permission everywhere" strikes me as massively broken. 3. On an API level, I'd like to see this API be the first to support a parameter on all GET requests that causes that request to not only return the serialization of that single object, but all the related objects as well. For example, the GET /tenant/<tenant_id> call by default would have a "domain_id" attribute, but with this flag it would have a "domain" attribute containing the entire serialized domain object. As for the name of this flag, I don't feel strongly. Django calls this concept "select_related", sqlalchemy calls it "eagerload". We could pick whatever we like here, but I'll be asking for this in Nova, et. al.'s APIs going forward too. 4. In the "you probably don't even want to touch it" category: have you given any thought to password reset functionality? Obviously it's backend dependent, but having some general concept of "forgot password"/"forgot username" would be important to end users in many cases. There are three cases I can see depending on backend: directly provide a password reset mechanism where possible; provide instructions for password reset (configured by system admin) where there is an external process in place; return Not Implemented when neither previous case is satisfied. I'm not saying this *must* appear in this API spec, but it's worth mentioning. Thanks for all the work on this. It's really looking great! - Gabriel From: openstack-bounces+gabriel.hurley=nebula....@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula....@lists.launchpad.net] On Behalf Of Joseph Heck Sent: Sunday, June 17, 2012 3:09 PM To: openstack@lists.launchpad.net (openstack@lists.launchpad.net) Subject: [Openstack] Keystone API V3 - draft 2 now available Draft 2 of the V3 Core Keystone API is now available for comment: https://docs.google.com/document/d/1_TkawQIa52eSBfS4pv_nx1SJeoBghIlGVZsRJJynKAM/edit In this revision, I've * updated the token structure a bit - to match the new resources * changed how the associations or user<->tenant through a role are enabled (POST instead of PUT) * put in detailed examples of responses to every call The general format of this documentation roughly follows the developer documentation at developer.github.com<http://developer.github.com>, which I thought had a pretty good model of showing how to use the APIs and describing the relevant pieces. There's a lot of cut and paste in there, so if something seems obviously wrong, it probably is ... please make a comment on the google doc and let me know. This document is far more structured and complete, and contains sufficient detail for those excited about WADLs and XSDs and such to create relevant mappings. Feedback needed please, comment away! -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
