Open Stack

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110509/b88390e6/attachment.html>