avoid swallow up the notification

[Lianhao Lu]

Currently, ceilometer doesn't use the 'pool' parameter when creating notification listener out of oslo.messaging. If there is another application creating the notification listener without setting the pool parameter too, that notification could only be received by either that application or ceilometer, but not by both of them. So either ceilometer or that application would miss that notification.

To avoid such conflict with other applications, we need to set the pool parameter. See http://docs.openstack.org/developer/oslo.messaging/notification_listener.html about how to use the pool parameter

[Lianhao Lu (lianhao-lu)]

After discussing with sileht, it seems having ceilometer set pool param has some side effect with current oslo.messaging. Ceilometer might lose the notification if restarting rabbitmq and if a notification is sent before ceilometer is reconnect to rabbitmq.

only notifications.XXXX queue are always present and ensure ceilometer to not miss notification. So we need to stick the current implementation before we make it configurable in oslo.messaging the list of queue that the notifier must ensure that exists.

[Lianhao Lu (lianhao-lu)]

besides, set the pool param seems preventing ceilometer receiving notifications in normal cases, see http://logs.openstack.org/07/193407/1/check/check-tempest-dsvm-full/bf1debf/

But that seems related to oslo.messaging, not ceilometer itself.

[Lianhao Lu (lianhao-lu)]

ok, the pool param works fine. But there is bug in glance/ceilometer coordination, see bug #1467776.

And also according to comment #1, we can't fix this until we make it configurable in oslo.messaging the list of queue that the notifier must ensure that exists.

[OpenStack Infra (hudson-openstack)]

Change abandoned by gordon chung (<email address hidden>) on branch: master
Review: https://review.openstack.org/193407
Reason: clean up

[gordon chung (chungg)]

i think we've given up on this and it should really be a oslo.messaging issue.