Bug 1297785 - Decouple transport for RPC and Notification [NEEDINFO]
Decouple transport for RPC and Notification
Status: CLOSED ERRATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-oslo-messaging (Show other bugs)
8.0 (Liberty)
Unspecified Unspecified
unspecified Severity medium
: ---
: 8.0 (Liberty)
Assigned To: Flavio Percoco
Ofer Blaut
: ZStream
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-12 08:12 EST by Flavio Percoco
Modified: 2016-06-29 09:47 EDT (History)
7 users (show)

See Also:
Fixed In Version: python-oslo-messaging-2.5.0-7.el7ost
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-06-29 09:47:59 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
fpercoco: needinfo? (hguemar)


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1504622 None None None 2016-01-12 08:31 EST
OpenStack gerrit 233258 None None None 2016-01-12 08:32 EST

  None (edit)
Description Flavio Percoco 2016-01-12 08:12:27 EST
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.
Comment 2 Victor Stinner 2016-01-12 08:33:10 EST
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.
Comment 3 Mehdi ABAAKOUK 2016-01-14 11:49:07 EST
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.
Comment 5 Flavio Percoco 2016-05-19 02:15:24 EDT
This patch seems to have been merged but not build, which is strange. Perhaps the latest build didn't have an updated patches branch?
Comment 7 Ofer Blaut 2016-06-28 14:09:33 EDT
code verified on python-oslo-messaging-2.5.0-7.el7ost.noarch
Comment 9 errata-xmlrpc 2016-06-29 09:47:59 EDT
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

Note You need to log in before you can comment on or make changes to this bug.