NotificationSystem

Launchpad Entry: NovaSpec: notification-system
Created: 3 February 2011
Contributors: Glen Campbell

Summary

Nova has a need to make notifications available to users in as close to a real-time manner as is feasiable. The proposed solution is to implement a PubSubHubbub (PSH) mechanism where Nova will create notifications in standard Atom 1.0 format and notify the PSH hub, and clients subscribe to the appropriate notifications to receive updates when their are notifications waiting.

PubSubHubbub (PSH) is an open protocol developed at Google and maintained at http://code.google.com/p/pubsubhubbub/.

Nova should not necessarily have to implement a hub from scratch, since there are several reference hubs available. However, Nova should make extensions/modifications to an existing hub to support access control for content. Specifically, if a cloud is being shared among multiple tenants (projects, customers), the administrator may not want notifications for one tenant being made available to other tenants. Nova will need to provide access controls so that one tenant (identified by an "account number" string) will not be able to access other tenants.

Release Note

The PubSubHubbub reference hub provided by Nova packages an open-source hub along with access controls that permit authentication to restrict access to certain data.

Rationale

By using PubSubHubbub (PSH), Nova can publish notifications (for example, exception logs or usage data) to a set of subscribers without needed to define interfaces for each specific use case. PubSubHubbub is a well-known, open-source standard that is based upon existing IEF technologies (Atom). Moreover, by ensuring that notifications are in a standard format, users of Nova will be able to access them via many existing technologies, including most modern web browsers. Finally, because PSH supports the concept of "ping" upon content creation, these notifications can be delivered in a near real-time basis.

User stories

As a Nova administrator, I need to receive notifications in a timely manner so that I can respond to emergencies.

As a Nova administrator, I need to support multiple clients for content easily so that I do not need to use my resources to develop individual interfaces.

As a systems integrator, I want to receive timely updates of usage data and disperse them to various customers (both internal and external) for billing, decision support, and analytic purposes.

Assumptions

Design

General Requirements

Services or components that produce notifications MUST make those notifications available in Atom 1.0 format.
There MUST be a central configuration setting that defines zero or more hubs to be used for notifications.
If there is at least one hub defined for notifications, then the service or component Atom feed MUST contain the link to the hub: <link rel="hub" … />
If there is at least one hub defined for notifications, then the service or component SHOULD notify the hub when new notification(s) are available. See http://code.google.com/p/pubsubhubbub/wiki/PublisherClients for example code.
The PSH hub MUST behave according to the PSH specification (with the possible exception of the access controls defined below).

Hub Development

Nova should not have to develop a hub from scratch; a number of hubs have been implemented and are available in open-source format. This page lists some available hub implementations:

http://code.google.com/p/pubsubhubbub/wiki/Hubs

Access Control

While the PSH protocol does not formally support access control (it is, of course, intended to be a publication system), some users have implemented ACLs on top of it. Nova should implement one of those systems on top of its chosen hub.

PSH for Private Feeds: https://docs.google.com/a/xlerb.com/document/pub?id=1HrVmSCQM2r5bCnQk5uZPbhH0sGVHHFOGhxJ0thoKEO8&ndplr=1&pli=1

Suprfeedr uses a publisher callback mechanism: http://blog.superfeedr.com/PubSubHubbub/Spec/Extension/publisher-callback-extension/

Discussion on access controls at the PSH website: http://groups.google.com/group/pubsubhubbub/browse_thread/thread/96b6b3ead71dd1ed

The implementor should choose one of these methods that best fits the current Nova authentication pattern(s).

Dependencies

Multi-tenant accounting - Hub access control is performed via accountID as defined in the multi-tenant spec.

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Migration

Include:

data migration, if any
redirects from old URLs to new ones, if any
how users will be pointed to the new way of doing things, if necessary.

Test/Demo Plan

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.