remove token from notifier middleware

notifier middleware is capturing token and sending it to MQ. this
is not advisable so we should filter it out.

Change-Id: Ia1bfa1bd24989681db1d2f385defc12e69a01f8d
Closes-Bug: #1321080
Remove low-value logging from publication codepath

Previously, the pipeline publish codepath emitted log messages
with almost no diagnostic value other than a "comfort bump".
However the sheer volume of these message was overwhelming
logstash in the CI gate.

We remove the worst offenders from that codepath.

Change-Id: If630593e8f755ccc1ede16941459daac30d284ff
Closes-Bug: #1328596
(cherry picked from commit 5f8a1fbf804c9572b777eb6af3d24cf9a98df758)
Bump stable/icehouse next version to 2014.1.2

Change-Id: Id7181755d3609c0ae91c2402b34f2de02c06a1f0
Merge "remove token from notifier middleware" into stable/icehouse
Adds Content-Type to alarm REST notifier

When doing a POST request in the REST alarm notifier,
we should include a Content-Type: 'application/json' header.

Conflicts:
	ceilometer/alarm/notifier/rest.py
	ceilometer/tests/alarm/test_notifier.py

Closes-Bug: #1346147
(cherry picked from commit 297a1b48183b476968164158584017e7a56ccf2b)
Change-Id: Ic02c8caeb294763443858dbbb3192e09c594c8cf
Merge "Remove low-value logging from publication codepath" into stable/icehouse
Updated from global requirements

Change-Id: If561d6513a0720192e188af4d13e87dafbeab3fc
Sync RPC module from oslo, fixing reconnect failures

This change syncs the following patches from oslo-incubator RPC:
- I67923cb024bbd143edc8edccf35b9b400df31eb3
- Ia148baa6e1ec632789ac3621c85173c2c16f3918

RabbitMQ: advance thru the list of brokers on reconnect

In RabbitMQ implementation, when using multiple rabbit_hosts, we don't want to
immediately retry failed connection for the same failed broker. This was not
the case in existing implementation though, where we've always attempted to
reconnect starting from the first broker in the list of candidates. So if the
first broker failed, we initiated reconnect to the same failed broker.

This change makes reconnect() implementation to select the next broker in the
list. This also means that non-failure reconnect attempts will also switch the
current broker. All in all, users should not rely on any particular order to
use brokers from the list, so this should not constitute an issue.

Qpid: advance thru the list of brokers on reconnect

In Qpid implementation, when using multiple qpid_hosts, we don't want to
immediately retry failed connection for the same failed broker. This was not
the case in existing implementation though, where we've always attempted to
reconnect starting from the first broker in the list of candidates. So if the
first broker failed, we initiated reconnect to the same failed broker.

This change makes reconnect() implementation to select the next broker in the
list. This also means that non-failure reconnect attempts will also switch the
current broker. All in all, users should not rely on any particular order to
use brokers from the list, so this should not constitute an issue.

Partial-Bug: #1261631
Change-Id: Ie9c4de2c094a5d420acca5e4a49ee6a36279ed87
Update ensure()/reconnect() to catch MessagingError

The error handling code that gets connections reset if necessary
caught ConnectionError. It really needs to catch MessagingError,
which ConnectionError inherits from. There are other types of
MessagingErrors that may occur, such as InternalError, and they need
to cause the connection to reset, as well.

This fix has already been merged into oslo.messaging.

--

Cherry-picked from oslo-incubator 234f64d608266f43d8856ff98c89ceba6699d752
See also https://bugzilla.redhat.com/show_bug.cgi?id=1086077

Closes-bug: #1303890
Change-Id: Ic5082b74a362ded8b35cbc75cf178fe6e0db62d0
Merge "Update ensure()/reconnect() to catch MessagingError" into stable/icehouse
Merge "Adds Content-Type to alarm REST notifier" into stable/icehouse
Revert "Simplify the dispatcher method prototype"

This reverts commit fe1158de8ca5f70fa219da706d4960b864654be7.
Add an RPC collector dispatcher

To support cells, ceilometer collectors need to form a
heirarchy where messages are forwarded upwards to a collector
at the API level.

This implements the dispatcher interface using oslo.rpc.proxy.RpcProxy
for message forwarding to a given transport_url. Multiple dispatchers
are still supported, so a compute-level collector may still store
samples in its own database if desired.

Conflicts:
	etc/ceilometer/ceilometer.conf.sample
	setup.cfg
Spool metering messages to reduce mq connections