← Back to team overview

openstack team mailing list archive

Re: Notifications proposal


On May 10, 2011, at 11:07 AM, Matt Dietz wrote:

Alright, I'll buy it. Simply adding a UUID would be trivial


Regarding categories, I tend to agree with Jay on this. I think it would
be treacherous to try to account for any number of possibilities, and I
also think that we need to keep this as simple as possible.

Okay fair enough,  the external publisher may create categories as needed.

On 5/10/11 10:35 AM, "Jay Pipes" <jaypipes@xxxxxxxxx<mailto:jaypipes@xxxxxxxxx>> wrote:

On Mon, May 9, 2011 at 11:58 PM, Jorge Williams
<jorge.williams@xxxxxxxxxxxxx<mailto:jorge.williams@xxxxxxxxxxxxx>> wrote:
On May 9, 2011, at 6:39 PM, Matt Dietz wrote:

  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
publisher I've implemented actually does all of the pubsubhubbub
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
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
example of an event that would span multiple categories?

>From an Atom perspective, I suppose anything a client might want to key
on or subscribe to may be a category.  So "create" may be a category --
billing layer may key in on all create messages and ignore others.
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
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
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

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

Hope that makes sense.


Follow ups