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