Notes in preparation for Notifications {as-a-contract, standardization} .

See also (the much older and very drafty) ImprovingNotifications .

One of the benefits of notifications over polling is that anything that can hear the notification messages can, with a little bit of effort, consume those messages. Preserving that flexibility is critical to allowing a healthy telemetry ecosystem. Whatever else is done to maintain the robustness of the boundaries between systems we need to make sure that adding new systems is not negatively impacted. Ideally it would be positively impacted.

Initially I was concerned that building contracts and versioning into notifications would make it harder for a multiplicity of tools to participate in processing those notifications. I've gotten over those concerns, but only because people have been fairly explicit about committing to ensuring that the contracts will be made available in a form that is independent of any particular tool or codebase.

But that only gets one side of the equation (easy consumption). What about a service which wants to start publishing a new set of notifications in a heretofore unused format? What is the procedure for adding new standards and new contracts?

In the past when it has been time to consume new meters in Ceilometer it has been necessary to write new code (a NotificationPlugin). This is incredibly wasteful. What would be better is a way to declare, in configuration, a transformation from a notification message structure to a Sample. Want new meters? Just add to the configuration.