Open Stack

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.

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