[openstack-dev] [all] Treating notifications as a contract

Sandy Walsh sandy.walsh at RACKSPACE.COM
Fri Jul 11 13:01:46 UTC 2014


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





More information about the OpenStack-dev mailing list