On 7/10/2014 12:10 PM, Chris Dent wrote: > On Thu, 10 Jul 2014, Julien Danjou wrote: > >> My initial plan was to leverage a library like voluptuous to do schema >> based validation on the sender side. That would allow for receiver to >> introspect schema and know the data structure to expect. I didn't think >> deeply on how to handle versioning, but that should be doable too. > It's not clear to me in this discussion what it is that is being > versioned, contracted or standardized. > > Is it each of the many different notifications that various services > produce now? > > Is it the general concept of a notification which can be considered > a "sample" that something like Ceilometer or StackTack might like to > consume? >
The only real differences between a sample and an event are: 1. the size of the context. "Host X CPU = 70%" tells you nearly everything you need to know. But "compute.scheduler.host_selected" will require lots of information to tell you why and how "host X" was selected. The event payload should be atomic and not depend on previous events for context. With samples, the context is sort of implied by the key or queue name. 2. The handling of Samples can be sloppy. If you miss a CPU sample, just wait for the next one. But if you drop an Event, a billing report is going to be wrong or a dependent system loses sync. 3. There are a *lot* more samples emitted than events. Samples are a shotgun blast while events are registered mail. This is why samples don't usually have the schema problems of events. They are so tiny, there's not much to change. Putting a lot of metadata in a sample is generally a bad idea. Leave it to the queue or key name. That said, Monasca is doing some really cool stuff with high-speed sample processing such that the likelihood of dropping a sample is so low that event support should be able to come from the same framework. The difference is simply the size of the payload and if the system can handle it at volume (quickly and reliably). _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
