On 09/04/2015 07:15 AM, Sean Dague wrote: > On 09/02/2015 05:48 PM, Matt Riedemann wrote: >> >> >> On 9/2/2015 3:40 PM, Jeremy Stanley wrote: >>> On 2015-09-02 10:55:56 -0400 (-0400), d...@doughellmann.com wrote: >>>> We are thrilled to announce the release of: >>>> >>>> python-novaclient 2.27.0: Client library for OpenStack Compute API >>> [...] >>> >>> Just as a heads up, there's some indication that this release is >>> currently broken by many popular service providers (behavior ranging >>> from 401 unauthorized errors to hanging indefinitely due, it seems, >>> to filtering or not supporting version detection in various ways). >>> >>> https://launchpad.net/bugs/1491579 >>> >> >> And: >> >> https://bugs.launchpad.net/python-novaclient/+bug/1491325 >> >> We have a fix for ^ and I plan on putting in the request for 2.27.1 >> tonight once the fix is merged. That should unblock manila. >> >> For the version discovery bug, we plan on talking about that in the nova >> meeting tomorrow. > > The issues exposed in novaclient version detection working correctly > against various clouds has now be fixed in 2.28.0 - the bug > https://bugs.launchpad.net/python-novaclient/+bug/1491579 has been > updated to hopefully contain all the relevant details of the issue.
It also looks like a big reason that this unexpected behavior in the field existed was because configuring SSL termination correctly (so that link following in the rest documents work) requires setting a ton of additional and divergent configuration options in various services. Thanks for folks looking into the issue in the bug and helping explain the behavior we saw. We're not yet testing for that in Tempest, so people are probably not realizing that their API environments are a bit janky. Honestly, the fact that deployers are required to do this is crazy. The service catalog already has this information, and the services should be reflecting this back. However people spent a lot of time working around the service catalog here probably because they didn't understand it, and creating a configuration hairball in the process. This I think raises the importance of really getting the Service Catalog into shape in this next cycle so that we can get ahead of issues like this one in the future, and actually ensure that out of the box cloud installs work in situations like this. -Sean -- Sean Dague http://dague.net __________________________________________________________________________ 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