In OpenStack there exists a general class of thing called a "notification". These are messages on the "bus" which serve a variety of purposes. That is they are "consumed" for different reasons:

• as metrics (c.f Ceilometer)
  • thing X (this instance) is using volume Z of thing Y (memory)
• as events (c.f. StackTach)
  • thing X (this instance) changed on some dimension (was created)
• as UX-drivers (c.f. Horizon)
  • ???
• as entitlement-enforcement (c.f. Katello)
  • ???

Different services create notifications onto an exchange with a topic. The notifications can be represented as a multiply nested dictionary. At the highest level, the notifications have a required format. Within a payload key, the format has been informal: services create the notifications that fit their needs.

This has pros and cons:

Pros

• Notifications can be added by a service without needing to consult some central authority or community. They can just get on with it.
• There are no constraints on the content of the message meaning it is easy to encapsulate the data in a form that is fit for the known purposes.

Cons

• Consumers are required to know at least a bit about the structure and meaning of the payload. This often means custom code to consume a particular type of notification resulting in a tight coupling between the notifier and the consumer(s).
• New consumers must do quite a bit of research and discovery to be correct.

An improved model could extend the known structure down to the next one or two layers of the nested dictionary. This would allow anything that knows the structure to at least injest and record notifications if not fully consume the meaning of them. At the same time any service which wanted to send notification would know that as long as they followed the correct format they could join a notification and consumption ecosystem.

Related Goals

This discussion was started in this thread where the following outcomes were listed as desirable (and then I drove the bus into the weeds):

1. more complete in-tree test coverage of notification logic on the producer side
2. versioned notification payloads to protect consumers from breaking changes in payload format
3. external discoverability of which event types a service is emitting
4. external discoverability of which event types a service is consuming

These goals were driven by difficulties with tracking and testing changes in notification formats across releases of the various OpenStack services.

Or to put it another way: the lack of contract across the messaging bus leads to ambiguity which makes management difficult. One way to fix that is to schematize and version the different classes of notifications.

While this is probably a good idea, doing it willy nilly, without a larger standard for notifications in general, will not solve enough problems to warrant the cost. If all the projects are going to take on the cost of revamping their notifications then it may as well involve an abstraction which can be reified in library code that is used intra-project.

Prior Art

CADF appears to be a standard that would like to be the leader in this environment. Their blurb:

Concerns over cloud provider security remain one of the top inhibitors to adoption of cloud deployment models. Potential consumers of cloud deployments understand and need assurance that the security policies they require on their applications are consistently managed and enforced “in the cloud” as they would be in their enterprise.

A cloud provider’s ability to provide specific audit event, log and report information on a per-tenant and application basis is essential. It is apparent that in order to meet these customer expectations, cloud providers must provide standard mechanisms for their tenant customers to self-manage & self audit application security that includes information about the provider’s hardware, software and network infrastructure used to run specific tenant applications.

We propose that the best way to address these requirements is by developing open standards for cloud auditing. These standards would support the submission and retrieval of normative audit event data from cloud providers in the form of customized reports and logs that can be dynamically generated for cloud customers using their criteria. Adoption of such open standards by cloud providers’ management platforms would go far to instill greater trust in “cloud hosted applications” and be a significant step forward in fulfilling the promise of an open cloud marketplace.

jd__ did some earlier work.

SandyWalsh points to.