Wow, that was the easiest resolution yet in mailing list land! ;) -jay
On Tue, May 10, 2011 at 12:22 PM, Jorge Williams <[email protected]> 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" <[email protected]> wrote: > > On Mon, May 9, 2011 at 11:58 PM, Jorge Williams > > <[email protected]> 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 : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
