Open Stack

Wow, that was the easiest resolution yet in mailing list land! ;)

-jay

On Tue, May 10, 2011 at 12:22 PM, Jorge Williams
<jorge.williams at rackspace.com> wrote:
>
> 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> wrote:
>
> 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
>
>
>