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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
