NotificationDispatcher should not use declare_topic_consumer (private method)

[Erica Windisch]

The method being used by NotificationDispatcher is not part of the RPC abstraction, but is an implementation detail of impl_kombu and impl_qpid.

The obvious choices are to make this a required part of the abstraction in openstack common, implementing it in impl_fake and impl_zmq, or changing the behavior of Quantum to use a standard create_consumer call.

Using create_consumer would NOT use notifications. The is currently no way to consume RPC-based notifications per the RPC API.

[dan wendlandt (danwent)]

Adding gary, yong, and mark, as they are probably best to common on this bug and triage it for RC1.

assigning to rc1 until we decide otherwise.

[Mark McClain (markmcclain)]

We should documented as a known limitation for Folsom. The zmq implementation in os-common needs to be updated to add support for notifications.

[Erica Windisch (ewindisch)]

Mark: a problem here is that NotificationDispatcher is using what is intended to be a private method. We have been discussing the addition of a public method that would satisfy this requirement.

[dan wendlandt (danwent)]

Plan is to fix this in Grizzly, likely with change to openstack-common. People with more insight into the issue than me can add more info :)

[Mark McLoughlin (markmc)]

This thread is also relevant: http://lists.openstack.org/pipermail/openstack-dev/2012-September/001068.html

[Erica Windisch (ewindisch)]

We're running out of time before Grizzly-3. Having Quantum fail to work with ZeroMQ because of a use of a private method of Kombu/Qpid will be pretty ugly.

Mark: do we need a blueprint for this specific issue? I did have a patch to bring the declare_topic_consumer() functionality into impl_zmq. It was reverted due to message envelope changes, but it can be restored without changing the envelope given a dependency on the advanced-matchmaker blueprint (which is presently in code review). Implementing the private method is ugly, but less ugly than having the code not work...

[Doug Hellmann (doug-hellmann)]

I had this blueprint for ceilometer. I don't know if there's a way to say it belongs in both projects.

https://blueprints.launchpad.net/ceilometer/+spec/move-listener-framework-oslo

[Mark McClain (markmcclain)]

Downgrading Quantum importance to match Oslo's grade.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/21919

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/21919
Committed: http://github.com/openstack/oslo-incubator/commit/74a9cbdc86580d256b6cd28ae57cd69213da6c44
Submitter: Jenkins
Branch: master

commit 74a9cbdc86580d256b6cd28ae57cd69213da6c44
Author: Doug Hellmann <email address hidden>
Date: Wed Feb 13 18:02:22 2013 -0500

    Add join_consumer_pool() to RPC connections

    blueprint move-listener-framework-oslo
    bug 1047015
    bug 1111632

    Ceilometer and Quantum use private methods of the RPC connection
    object to configure themselves to listen to a queue shared among a
    group of workers. This change adds a public method to the RPC
    connection to support this use case, without resorting to using
    private API calls.

    Change-Id: I3a89f1dfdcf8accca70cf305f7a31315bea093d8
    Signed-off-by: Doug Hellmann <email address hidden>

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/22697

[Mark McClain (markmcclain)]

Recent multi-agent changes have removed this code from Quantum.