Open Stack

On Mon, May 9, 2011 at 11:58 PM, Jorge Williams
<jorge.williams at rackspace.com> wrote:
> On May 9, 2011, at 6:39 PM, Matt Dietz wrote:
>
> Jorge,
>    Thanks for the feedback!
>    Regarding the message format, we actually don't need the unique id in the
> generic event format because that's implementation specific. The external
> publisher I've implemented actually does all of the pubsubhubbub specific
> heavy lifting for you. The idea behind keeping this system simple at the
> nova layer is allowing people to implement anything they'd like, such as
> emails or paging.
>
> I guess, I'm not seeing the whole picture.  So these are internal messages?
> Will they cross service boundaries / zones?  I'm sorry I missed the
> conversation at the summit :-) Is there a blueprint I should be reading?

On this particular point, I agree with Jorge. A unique identifier
should be attached to a message *before* it leaves Nova via the
publisher. Otherwise, subscribers will not be able to distinguish
between different messages if more than one publisher is publishing
the message and tacking on their own unique identifier.

For instance, if a Rabbit publisher and email publisher are both
enabled, and both attach a unique identifier in a different way,
there's no good way to determine two messages are the same.

> For categories, were you considering this to be a list? Could you give an
> example of an event that would span multiple categories?
>
> From an Atom perspective, I suppose anything a client might want to key in
> on or subscribe to may be a category.  So "create" may be a category -- a
> billing layer may key in on all create messages and ignore others. "compute"
> may also be a category -- you can aggregate messages from other services so
> It'd be nice for messages from compute to have their own category.  To my
> knowledge, atom doesn't have the concept of priority so "WARN" may also be a
> category.  I suppose if these are internal messages an external publisher
> can split the event_type and priority into individual categories.

I disagree with this assessment, Jorge, for this reason: attempting to
identify all the possible categories that an organization may wish to
assign to a particular event may be near impossible, and in all
likelihood, different deployers will have different categories for
events.

I think a solution of codifying the event_type in the message to a
singular set of strings, with a single dotted group notation (like
"instance.create" or something like that) is the best we can do. The
subscriber of messages can later act as a translation or aggregator
based on the business rules in place at the deployer. For example,
let's say a deployer wanted to aggregate messages with event_type of
"instance.create" into two categories "instance" and "create". A
custom-written subscriber could either do the aggregation itself, or
modify the message payload to include these custom deployer-specific
categories.

Hope that makes sense.

-jay