Open Stack

On Thursday afternoon we had a nova/keystone cross-project design summit 
session. The session etherpad with full details is here [1].

This session was mostly about a nova spec [2] to fix a long-standing bug 
in Nova. We've actually had several duplicate bugs for this issue, which 
is why we're working on the spec again to resolve it.

The issue is that when a nova admin is setting quota or flavor access 
they are passing a project id (not their own) which is not validated to 
actually exist with keystone. So if there is a typo, or a name is passed 
rather than an id, Nova will persist that and say the operation was 
successful, but it's useless.

Some attempts have been made to do at least checking on the id so that 
it's a UUID, but project IDs don't have to be UUIDs, so we've rejected 
those types of fixes for now. And we don't really want python-novaclient 
doing the check with keystone since we really need to handle this in the 
Nova REST API for all clients.

The spec was originally written to add new policy to keystone and add 
keystone admin credentials to nova.conf to perform the lookup, but 
that's since been rejected (it's not a good idea for Nova to have 
keystone admin credentials).

We then talked about whether or not to rely on a nova service user, but 
ultimately decided against that.

So the plan is to re-use the Nova admin context passed in to perform a 
check in keystone (HEAD or GET) with the given project_id which will 
either fail or pass, and Nova can handle the result appropriately:

* If Nova gets a 200, then the ID exists and we continue processing the 
request.

* If Nova gets a 403 then we don't have access to Keystone to perform 
the check (the deployer would have to adjust Keystone's policy.json to 
allow this). In this case I think we continue as we do today, maybe 
logging a warning. Details on that will be sorted out in the spec review.

* If Nova gets a 404 then the ID isn't valid and we return a 400 to the 
user.

There were some clarifying questions already in the dev list [3].

We also agreed that the Nova REST API won't be accepting a tenant name 
lookup, that convenience can happen in clients like 
python-openstackclient which already accepts name or id for project inputs.

We had some time left at the end of the session to cover two other items.

oslo.policy changes for policy defaults in code
-----------------------------------------------

This was just a nod to the Keystone team to review Andrew Laski's specs 
[4], one of which is already approved (thanks Keystoners - is that what 
you call yourselves?).


Service users between projects to avoid token timeouts
------------------------------------------------------

The idea here is to pass user information (user, role, project IDs) and 
service token and KSA will check the expiration on the service token. 
This is not yet implemented in KSA. The Keystone team is hoping to merge 
this code in Newton so Nova could use it in Ocata. The good news is most 
everything Nova is using for clients, e.g. cinderclient, glanceclient, 
neutronclient, etc, are already using KSA.

This would also be an additive change to the context so it will work 
with older computes. The only catch with this is you can't set the token 
timeouts low until your nova computes are upgraded and using the updated 
context. A multi-node CI job should be able to tease out issues with 
this though.

[1] https://etherpad.openstack.org/p/newton-nova-keystone
[2] https://review.openstack.org/#/c/294337/
[3] http://lists.openstack.org/pipermail/openstack-dev/2016-May/094096.html
[4] 
https://review.openstack.org/#/q/project:openstack/oslo-specs+branch:master+topic:policy_generation


-- 

Thanks,

Matt Riedemann