Nova quota show/set give errors in verify_project_id

Bug #1693228 reported by Marcus Murwall
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Fix Released
Undecided
Sean Dague
Ocata
New
Undecided
Unassigned

Bug Description

Description
===========

'openstack quota show <project>' gives error in ocata.

Log:
2017-05-24 11:32:27.666 21595 DEBUG nova.api.openstack.wsgi [req-2fdb7c04-35d4-4cd3-aa12-9dd7a835db25 aad396bff0834baeb50beda5ade6ccaa aaf41996573a47ab996a9876313caaaa - default default] Calling method '<function version_select at 0x7f39f5828398>' _process_stack /openstack/venvs/nova-master/lib/python2.7/site-packages/nova/api/openstack/wsgi.py:624
2017-05-24 11:32:28.143 21595 INFO nova.api.openstack.wsgi [req-2fdb7c04-35d4-4cd3-aa12-9dd7a835db25 aad396bff0834baeb50beda5ade6ccaa aaf41996573a47ab996a9876313caaaa - default default] HTTP exception thrown: Project ID aa4664722c924c979953bf264c4044aa is not a valid project.
2017-05-24 11:32:28.147 21595 DEBUG nova.api.openstack.wsgi [req-2fdb7c04-35d4-4cd3-aa12-9dd7a835db25 aad396bff0834baeb50beda5ade6ccaa aaf41996573a47ab996a9876313caaaa - default default] Returning 400 to user: Project ID aa4664722c924c979953bf264c4044aa is not a valid project. __call__ /openstack/venvs/nova-master/lib/python2.7/site-packages/nova/api/openstack/wsgi.py:1041

After some digging the error seems to be that in file:
https://github.com/openstack/nova/blob/master/nova/api/openstack/identity.py#L34

on line 34 the code reads: 'resp = sess.get('/v3/projects/%s' % project_id'

It seems incorrect to enforce v3 endpoint here. Both due to that some are still using v2.0, and also because the endpoints for identity normally already includes the endpoint.
Before the request is sent to identity the url is merged with base url (In file: keystoneauth1/session.py line 516).
This results in an incorrect path with duplicate versions, that looks something like: http://<domain:port>/v3/v3/projects/<project_id>
..which in turn gives a 404 response back to nova. Nova will present this as a 400 error stating the project does not exist.

Changing the code from:
'resp = sess.get('/v3/projects/%s' % project_id'
to
'resp = sess.get('/projects/%s' % project_id'

..will fix this particular issue and so far I have not seen any other impact and to me is seems logical to let the endpoint define versioning rather than enforcing it.

Steps to reproduce
==================
Use openstack client and run: openstack quota show <project>

Expected result
===============
Getting a result of project quota

Actual result
=============
Nova returns 400 error: 'Project ID <project_id> is not a valid project'

Environment
===========
Ocata version running on KVM
Installed via openstack-ansible
Ceph backend
Neutron

Revision history for this message
Matt Riedemann (mriedem) wrote :

Keystone v2 has been deprecated since I think the Mitaka release, but I agree that if we don't need to we shouldn't munge the v3 into the URL.

Changed in nova:
status: New → Triaged
tags: added: api keystone quotas
Revision history for this message
Matt Riedemann (mriedem) wrote :

This is also going to be an issue for the os-flavor-access API in the Pike release.

Revision history for this message
Matt Riedemann (mriedem) wrote :

Hmm, although, the keystone v3 API reference explicitly makes it look like you should be specifying /v3/:

https://developer.openstack.org/api-ref/identity/v3/#show-project-details

Revision history for this message
Matt Riedemann (mriedem) wrote :
Changed in nova:
assignee: nobody → Sean Dague (sdague)
status: Triaged → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to nova (master)

Reviewed: https://review.openstack.org/438049
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=4a2009a6fa2017013102d3d43e670334ebc60d9f
Submitter: Jenkins
Branch: master

commit 4a2009a6fa2017013102d3d43e670334ebc60d9f
Author: Sean Dague <email address hidden>
Date: Fri Feb 24 13:56:03 2017 -0500

    Be more tolerant of keystone catalog configuration

    The previous attempt at validating against keystone assumed that users
    had an unversioned endpoint in their catalog. Most do not. This uses
    the keystoneauth discovery magic to do the right thing whether or not
    they have the versioned or unversioned endpoint, as long as they have
    a working v3 installation.

    It is also much more verbose on log messages when things go wrong.

    Change-Id: I509d406ca1f1f7b064aaca88645ad17685827267
    Related-Bug: #1667679
    Closes-Bug: #1693228

Changed in nova:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/nova 16.0.0.0b2

This issue was fixed in the openstack/nova 16.0.0.0b2 development milestone.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.