[openstack-dev] [openstack-announce] [release][nova] python-novaclient release 2.28.0 (liberty)

Sean Dague sean at dague.net
Fri Sep 4 11:29:45 UTC 2015


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), doug at 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



More information about the OpenStack-dev mailing list