Updated openstack/openstack
Project: openstack/oslo.config  58d7d2f0502d9cc1a149d58f742441c481323c7c
null
Follow style guide for help strings

Improve help strings to follow the style guide:
* Capitalize first word of each help string
* Finish help strings with "."
* Improve wording and follow usual capitalization

Change-Id: Iecab34edd35175dcf1cccd4676e5cd91752549ad
Updated openstack/openstack
Project: openstack/oslo.config  a5faf6b79fc0957665f4f6d16538c9d470f59a0e
null
Do substitution on overrides and defaults too

Some of our consuming projects are setting defaults or overrides
on config objects that look like $state_path/some/file and we're
no longer handling that correctly since commit
2422d4118c97734067ea0b37ae159bc2e3c492c5

Change-Id: I4324bda6f3de3cdf05f8eb3cf16052c04018dec8
Closes-Bug: #1282250
Updated openstack/openstack
Project: openstack/oslo.messaging  5594a57012bf980895a601c47acf90a0e50f3d59
null
Gracefully handle consumer cancel notifications

With mirrored queues and clustered rabbit nodes a queue is still
mastered by a single rabbit node. When the rabbit node dies an
election occurs amongst the remaining nodes and a new master is
elected. When a slave is promoted to master it will close all the
open channels to its consumers but it will not close the
connections. This is reported to consumers as a consumer cancel
notification (CCN). Consumers need to re-subscribe to these queues
when they recieve a CCN.

kombu 2.1.4+ reports CCNs as channel errors. This patch updates
the ensure function to be more inline with the upstream kombu
functionality. We now monitor for channel errors as well as
connection errors and initiate a reconnect if we detect an error.

Change-Id: Ie00f67e65250dc983fa45877c14091ad4ae136b4
Partial-Bug: 856764
Updated openstack/openstack
Project: openstack/oslo.messaging  491414408b6049dd8b3babe5ae6c9404644b4a3b
null
Slow down Kombu reconnect attempts

For a rationale for this patch, see the discussion surrounding Bug

When reconnecting to a RabbitMQ cluster with mirrored queues in
use, the attempt to release the connection can hang "indefinitely"
somewhere deep down in Kombu.  Blocking the thread for a bit
prior to release seems to kludge around the problem where it is
otherwise reproduceable.

DocImpact

Change-Id: Ic2ede3046709b831adf8204e4c909c589c1786c4
Partial-Bug: 856764