Notification subscriber server
This cover a needs for ceilometer to migrate to oslo.messaging
The idea is have a simple API to subscribe to raw notification message. The API will looks like the RPC server one.
To share the code of the MessageHandling
The target must allow to acknowledge/requeue message manually.
Example of usage:
class Endpoint(object):
def warn(self, ctxt, publisher_id, event_type, payload, extras):
target = messaging.
listener = notify.
Blueprint information
- Status:
- Complete
- Approver:
- Mark McLoughlin
- Priority:
- High
- Drafter:
- Mehdi Abaakouk
- Direction:
- Approved
- Assignee:
- Mehdi Abaakouk
- Definition:
- Approved
- Series goal:
- Accepted for icehouse
- Implementation:
-
Implemented
- Milestone target:
-
1.3.0
- Started by
- Mark McLoughlin
- Completed by
- Doug Hellmann
Related branches
Related bugs
Sprints
Whiteboard
Gerrit topic: https:/
Addressed by: https:/
Implementation of notification subscriber server
---
Thanks for this! Before I really dig into reviewing, I sketched out what my default approach to the API would have been. That's not to say mine is better, it's just my starting point before even looking at your code:
from oslo.config import cfg
from oslo import messaging
transport = messaging.
class InfoHandler(
def info(self, ctxt, publisher_id, event_type, payload):
...
class WarnHandler(
def warn(self, ctxt, publisher_id, event_type, payload):
...
endpoints = [
InfoHandl
WarnHandl
]
target = messaging.
listener = messaging.
-- @markmc
--
Note also, I think we might benefit in the longer term from a type of declarative filter that different transport drivers could implement cleverly - i.e. rather than doing:
class WarnHandler(
def warn(self, ctxt, publisher_id, event_type, payload):
if not publisher_
you'd instead do something like:
class WarnHandler(
filter = NotificationsFi
def warn(self, ctxt, publisher_id, event_type, payload):
...
but we'd really need a driver that would do something useful with it before implementing it. The tricky part is that if we based it on regular expressions, you probably limit what kind of drivers you can write. But if you don't base it on regular expressions, you limit what you can express in the filter.
-- @markmc
Addressed by: https:/
Remove the partial implementation of ack_on_error
Addressed by: https:/
Abstract the ack/requeue/reject layer of a message
Addressed by: https:/
Do the acknowlegement of messages by the executor
Addressed by: https:/
Allow fake driver to consume multiple topics
Addressed by: https:/
Add a listener abstraction layer for notification
Gerrit topic: https:/
---
The blueprint description could do with being updated to reflect the new API -- @markmc
Addressed by: https:/
Make the executor responsible of the message ack
Addressed by: https:/
Allow to requeue the notification message
Addressed by: https:/
Make the dispatcher responsible to listen()
Addressed by: https:/
Add multiple exchange per listerner in fake driver
Gerrit topic: https:/
Addressed by: https:/
Allow missing data notification endpoint callback
Addressed by: https:/
Add transport reconnection retries
----
The remaining open review (https:/
Work Items
Dependency tree
* Blueprints in grey have been implemented.
