Open Stack

Sunday morning, and all that :-)

On 5/10/11 11:38 AM, "Jay Pipes" <jaypipes at gmail.com> wrote:

>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
>>
>>
>>