|
Red Hat Bugzilla – Full Text Bug Listing |
| Summary: | report proper error when the required API is not available | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Angus Salkeld <asalkeld> |
| Component: | python-novaclient | Assignee: | Jakub Ruzicka <jruzicka> |
| Status: | CLOSED WONTFIX | QA Contact: | Ami Jeain <ajeain> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 3.0 | CC: | 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
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. |