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.
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.
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
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
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.
Related upstream discussion http://lists.openstack.org/pipermail/openstack-dev/2012-December/004010.html
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.