Information Disclosure

Red Hat Enterprise Linux OpenStack Platform provides the facilities for building a private or public infrastructure-as-a-service (IaaS) cloud running on commonly available physical hardware. Changes to the ceph component: * In the previous version, launching of nova instances resulted in nova-compute to crash with a segmentation fault in certain cases when using Ceph RBD back end. This was due to the incorrect clean up in librbd1 packages. This has been fixed in this release, and nova-compute now operates correctly with Ceph RBD back end. (BZ#1182608) Changes to the python-novaclient component: * With this enhancement, a new command ‘service-delete’ has been added to the nova client to allow disabling services through the nova CLI as opposed to manually editing the nova-services table. (BZ#1206644) Changes to the python-requests component: * In the previous version, python-requests had issues including incorrect HTTP headers€™ generation, causing errors with python-swiftclient. This was due to python-requests having an incorrect implementation of a case insensitive mapping. With this release, case insensitive dictionary (CaseInsensitiveDict) has been updated which has fixed all issues with python-swiftclient. (BZ#1176181) Changes to the python-sqlalchemy component: * Previously, an improvement to the connection pool such that new connections could be made concurrently, made it so that the ‘init on first connect’ routine of a SQLAlchemy dialect would not have been completed if concurrent routines proceeded at the same time. As a result, when a SQLAlchemy engine was first used, operations which relied on the state acquired during initial startup could fail, as this information would not have been completed. To resolve this issue, with this update, ‘mutexing’ was added to the event system which handles the initial dialect startup phase, so that connection attempts are again serialized, but only when the engine first starts up. (BZ#1198773) * Previously, the MySQL-Python DBAPI was observed under some circumstances using the ProgrammingError exception class to report on the ‘command out of sync’ errors, which is considered to be the case where a connection need to be thrown away; the SQLAlchemy dialect only expected this error to be emitted within the OperationalError class. As a result, in some cases a MySQL-Python connection that became corrupt would not signal to the SQLAlchemy engine that the pool of connections should be disposed, leading the engine not being able to proceed with new operations. With this update, the error handling scheme of the MySQL-Python dialect is modified to expect either the OperationalError or ProgrammingError exception class when testing for this particular class of error. As a result, the SQLAlchemy engine/connection pool now correctly disposes off its connections when a MySQL-Python ProgrammingError delivers the ‘command out of sync’ error code. (BZ#1198774)