This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 889060

Summary: report proper error when the required API is not available
Product: Red Hat OpenStack Reporter: Angus Salkeld <asalkeld>
Component: python-novaclientAssignee: Jakub Ruzicka <jruzicka>
Status: CLOSED WONTFIX QA Contact: Ami Jeain <ajeain>
Severity: low Docs Contact:
Priority: low    
Version: 3.0CC: apevec, dallan, eglynn, sdake, yeylon
Target Milestone: ---Keywords: Reopened, Triaged
Target Release: 4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-05 10:39:39 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Angus Salkeld 2012-12-20 01:45:48 EST
Description of problem:

Installed everything on one machine (bare metal) via packstack.

source openrc

keystone service-list
+----------------------------------+-------------+----------+----------------------------+
|                id                |     name    |   type   |        description         |
+----------------------------------+-------------+----------+----------------------------+
| 173df6fd2016465590057d82d66dc9a9 |    cinder   |  volume  |       Cinder Service       |

etc... (keystone working)

nova list
(empty but no error)

but:

nova service-list
ERROR: n/a (HTTP 404)

from nova/api.log

2012-12-20 16:55:29 INFO nova.osapi_compute.wsgi.server [req-cb30e59d-c5b1-4bc1-a21e-bc37dd448291 e3354cfbb21f408cb6f20859ea65694a 23189d5b232347e0a442a375685bc43b] 127.0.0.1 - - [20/Dec/2012 16:55:29] "GET /v2/23189d5b232347e0a442a375685bc43b/os-services HTTP/1.1" 404 176 0.038225


ps -ef | grep nova
nova     21272     1  0 16:48 ?        00:00:01 /usr/bin/python /usr/bin/nova-api --config-file /etc/nova/nova.conf --logfile /var/log/nova/api.log
nova     21284 21272  0 16:48 ?        00:00:00 /usr/bin/python /usr/bin/nova-api --config-file /etc/nova/nova.conf --logfile /var/log/nova/api.log
nova     21330 21272  0 16:48 ?        00:00:00 /usr/bin/python /usr/bin/nova-api --config-file /etc/nova/nova.conf --logfile /var/log/nova/api.log
nova     21343 21272  0 16:48 ?        00:00:00 /usr/bin/python /usr/bin/nova-api --config-file /etc/nova/nova.conf --logfile /var/log/nova/api.log
nova     21837     1  0 16:49 ?        00:00:14 /usr/bin/python /usr/bin/nova-compute --config-file /etc/nova/nova.conf --logfile /var/log/nova/compute.log
nova     21926     1  0 16:50 ?        00:00:09 /usr/bin/python /usr/bin/nova-scheduler --config-file /etc/nova/nova.conf --logfile /var/log/nova/scheduler.log
nova     22133     1  0 16:50 ?        00:00:09 /usr/bin/python /usr/bin/nova-cert --config-file /etc/nova/nova.conf --logfile /var/log/nova/cert.log
nova     22184     1  0 16:51 ?        00:00:09 /usr/bin/python /usr/bin/nova-network --config-file /etc/nova/nova.conf --logfile /var/log/nova/network.log
root     25282 19222  0 17:44 pts/1    00:00:00 grep nova


Version-Release number of selected component (if applicable):
sudo rpm -q -a | grep openstack
openstack-nova-cert-2012.2.1-2.el6ost.noarch
openstack-swift-1.7.4-2.el6.noarch
openstack-glance-2012.2.1-1.el6ost.noarch
openstack-nova-scheduler-2012.2.1-2.el6ost.noarch
python-django-openstack-auth-1.0.2-3.1.el6.noarch
openstack-swift-plugin-swift3-1.0.0-0.20120711git.el6.noarch
openstack-packstack-2012.2.2-0.1.dev205.el6ost.noarch
openstack-keystone-2012.2.1-1.el6ost.noarch
openstack-cinder-2012.2.1-1.el6ost.noarch
openstack-nova-api-2012.2.1-2.el6ost.noarch
openstack-nova-compute-2012.2.1-2.el6ost.noarch
openstack-nova-network-2012.2.1-2.el6ost.noarch
openstack-nova-common-2012.2.1-2.el6ost.noarch
openstack-utils-2012.2-6.el6.noarch
openstack-dashboard-2012.2.1-2.el6ost.noarch


How reproducible: very


Expected results: no error.
Comment 2 Eoghan Glynn 2012-12-20 06:01:41 EST
This results from a mismatch between the branching of nova and python-novaclient.

We don't have a stable/folsom branch in the novaclient, and it looks like we're inadvertantly pulling stuff from python-novaclient:master that depends on recently added corresponding functionality in nova:master (that has not been backported to nova:stable/folsom).

This is a case in point, where the newly added os-services API extension in nova (intended to replace the 'nova-manage service list' command) is exposed in the RHOS novaclient package, but not supported yet by the version of nova we ship.

Oddly enough the problematic commit introducing the 'nova service-list' verb to novaclient doesn't appear to be present in:

  git://github.com/fedora-openstack/openstack-python-novaclient.git

So are we pulling the novaclient code directly from upstream?

In any case, work-around is simply to use 'nova-manage service list' instead.
Comment 3 Eoghan Glynn 2012-12-20 06:19:57 EST
As disccussed on IRC, we are currently shipping the latest python-novaclient tarball from upstream:

  http://pypi.python.org/pypi/python-novaclient/2.10.0

which depends on several nova features new in grizzly:

  https://lists.launchpad.net/openstack/msg19041.html
Comment 4 Eoghan Glynn 2012-12-20 06:36:46 EST
Further discussion on IRC, conclusions:

- the 404 errors resulting from the missing are not strictly considered a regression

- shipping net-new features in novaclient is therefore acceptable

- so we won't ship a novaclient version "closer" to Folsom (i.e. 2.9.0)

- however, other kinds of newness in novaclient (such as an across-the-board switch to a new v3 API) could be more problematic in the future

- so we may need to reconsider the policy of always shipping the latest novaclient tarball from upstream
Comment 5 Alan Pevec 2012-12-21 13:23:08 EST
IMHO this could be improved upstream: novaclient CLI should report proper error message when required API is not available. Looking at nova list-extensions there must be a way to query API endpoint to see what's supported on the remote side.
Comment 6 Alan Pevec 2012-12-21 15:01:11 EST
Related upstream discussion http://lists.openstack.org/pipermail/openstack-dev/2012-December/004010.html
Comment 9 Jakub Ruzicka 2013-11-05 10:39:39 EST
So from the thread Alan posted this seems to be a topic for upstream discussion about how this should be solved before fixing it, so I'm closing this downstream.

Also note that I'm not aware of any 404 with current client version.

Please report/discuss this upstream as you see fit.