openstack team mailing list archive

[Joe Heck <Joe.Heck@xxxxxxxxxx>]

Sorry for the delayed response - some bits inline.

On Jun 18, 2012, at 5:16 PM, Gabriel Hurley wrote:
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)?

Given that there's at least one person out there specifically asking for separated ports for concerns, I expect we will. I've got a request in to register a public port, and there will certainly be an option so that you can run everything on a single port (if you want), with the API's being protected by Keystone's RBAC. I've created a blueprint to cover making those implementations (https://blueprints.launchpad.net/keystone/+spec/rbac-keystone-api) to allow a single port if that's desired.

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.

My expectation is that there is a still a "keystone administrator" role that has access to administratively manage keystone - setting up domains, etc. That doesn't mean this role is or needs to be equivalent to a global "admin", and ideally that role would be *very* specific to Keystone and not propagate a global admin unless an implementation specifically wanted to do that. Back to my "there's a blueprint for that..." theme, we've set up a blueprint to gather and collate all the policy.json files and set up a recommended set of roles and policy files for deployment under https://blueprints.launchpad.net/keystone/+spec/document-deployment-suggestions-policy.

I'm thinking of this as an operational/deployment suggestion that's a step up from the devstack "verify this stuff, enough to get moving" with some recommendations that make sense for medium and larger sized deployments with multiple services and roles.

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.

My first reaction is "Sure, if you code it..." :-), but more seriously - how would you suggest passing that along through a REST API to ask for the various ID's to be fully fleshed out? Or would you simply want to make this something that client code could reasonably do as it reconstitutes the objects in the python library?

In the case of requesting a token in the V3 API draft, this is called out specifically as the expected result, where almost everything else will return an ID, but not necessarily embed additional "objects" in a cascade. The /token request use case being common enough that including the extra data up front will clearly reduce multiple calls for common use cases.

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.

Ha! Easiest one of all! For the back-ends that implement that functionality, password updates are doable using a PATCH request on the User resource, handing in a new password. Or at least that's the intention. If PATCH is not supported by the Auth backend, that will simply return a 501 Not Implemented.

-joe