Open Stack

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

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


Cool.

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 at gmail.com<mailto:jaypipes at gmail.com>> wrote:

On Mon, May 9, 2011 at 11:58 PM, Jorge Williams
<jorge.williams at rackspace.com<mailto: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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110510/268028f3/attachment.html>