In Mitaka, a series of patches decoupling the RPC and Notification layer landed. These patches allow for having 2 different brokers serving the notification layer and the RPC one respectively. The above allows for a better architecture as it'd be possible to separate the control broker from the one storing the notifications. In addition to this, the split would also allow for the OSP8 control layer to be deployed on top of the amqp1 driver and the notification one on top of a broker. It's important to note that this bug is not proposing to replace current deployments and the backported patches are backwards compatible. Therefore, existing customers and deployments won't be affected. The downside of this backport is that they'd be a downstream only backport as the upstream community won't be pulling these patches into Liberty.
The API was already approved by the Oslo (Messaging) team, the change was also reviewed and merged upstream, so I'm confident that the API is not going to change deeply next months. Flavio mentioned a performance issue which can be reduced by this new architecture. So it seems worth it to backport this feature.
This does magic only for the client side (emitting notification). For example, ceilometer needs to be changed to support that fully (server side). But I'm not against this change. It will not break anything.
This patch seems to have been merged but not build, which is strange. Perhaps the latest build didn't have an updated patches branch?
code verified on python-oslo-messaging-2.5.0-7.el7ost.noarch
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2016:1352
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days