Open Stack

> It's not clear to me in this discussion what it is that is being
> versioned, contracted or standardized.

Well the statement in the original mail was pretty explicit:

 "versioned notification payloads to protect consumers from breaking
  changes in payload format"

So it's the standardization of notification payload formats that's
being proposed.
 
> Is it each of the many different notifications that various services
> produce now?

Its the event types emitted and the version of each payload.

> Is it the general concept of a notification which can be considered
> a "sample" that something like Ceilometer or StackTack might like to
> consume?

Well, the notifications emitted are intended to be general-purpose
in nature.

Ceilometer, StackTack OTOH put those notifications to a specific
(and slightly different) purpose.

Having the services emit exactly the sample format that ceilometer
desired would save ceilometer itself doing the transformation, but
would make the notifications less useful to other consumers. 

> If it not the latter, why isn't it the latter?

For the reason state above.

> Here's some semi-random
> noodling:
> 
> Wouldn't the metering process be a lot easier if there was a
> standardized package for a "sample" and anyone with the proper
> credentials could drop a sample on the bus with the right exchange with
> the right topic and anything (e.g. Ceilometer, StackTack, the
> NewShinyMeteringShiz) that wants to consider itself a metering store can
> consume it and hey presto.

Problem is, the requirements of Ceilometer, StackTack, and indeed
NewShinyMeteringShiz, are probably gonna be different.
 
> If people are going to have to write a bunch of new tests and
> related code to get notifications healthier why not make
> notifications for metrics _healthy_ and available to any system
> without needing to write a bunch of code on both sides of the bus.

The intent was loose-coupling between the notifier and the notified.

These notifications pre-exist ceilometer, where never intended for
ceilometer's exclusive use, and are in current use by frameworks
other than ceilometer, each with differing requirements. 

> Currently Ceilometer is required to know far too much about the
> notifications it receives and that knowledge is being represented is
> code. That is a BadThing™. I'm sure there are plenty of reasons for
> why it has turned out that way, but if there is an opportunity for
> change...?

Not really, I don't think, TBH.

Cheers,
Eoghan