On May 9, 2011, at 5:20 PM, Matt Dietz wrote:
Message example:
{ 'publisher_id': 'compute.host1',
'timestamp': '2011-05-09 22:00:14.621831',
'priority': 'WARN',
'event_type': 'compute.create_instance',
'payload': {'instance_id': 12, ... }}
There was a lot of concern voiced over messages backing up in any of the
queueing implementations, as well as the intended priority of one message over
another. There are couple of immediately obvious solutions to this. We think
the simplest solution is to implement N queues, where N is equal the number of
priorities. Afterwards, consuming those queues is implementation specific and
dependent on the solution that works best for the user.
The current plan for the Rackspace specific implementation is to use
PubSubHubBub, with a dedicated worker consuming the notification queues and
providing the glue necessary to work with a standard Hub implementation. I have
a very immature worker implementation at https://github.com/Cerberus98/yagi if
you're interested in checking that out.
Some thoughts:
In order to support PubSubHubBub you'll also need each message to also contain
a globally unique ID. It would also be nice if you had the concept of
categories. I realize you kinda get that with the event type
"compute.create_instance" but there are always going to be messages that may
belong to multiple categories. Also, ISO timestamps with a T :
"2011-05-09T22:00:14.621831" are way more interoperable -- I would also include
a timezone designator Z for standard time 2011-05-09T22:00:14.621831Z --
otherwise some implementation assume the local timezone.
-jOrGe W.
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
