Sunday morning, and all that :-) On 5/10/11 11:38 AM, "Jay Pipes" <jaypi...@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.willi...@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" <jaypi...@gmail.com> wrote: >> >> On Mon, May 9, 2011 at 11:58 PM, Jorge Williams >> >> <jorge.willi...@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 >> >> >> _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
