Difference between revisions of "NotificationSystem"
| Line 46: | Line 46: | ||
Events must be available per host and per server. The following API resources should be available: | Events must be available per host and per server. The following API resources should be available: | ||
| − | <code><nowiki>/servers/{id}/events</nowiki></code> | + | <code><nowiki>/servers/{id}/events</nowiki></code> |
| − | <code><nowiki>/hosts/{id}/events</nowiki></code> | + | <code><nowiki>/hosts/{id}/events</nowiki></code> |
{| border="1" cellpadding="2" cellspacing="0" | {| border="1" cellpadding="2" cellspacing="0" | ||
Revision as of 17:28, 2 March 2011
- Launchpad Entry: NovaSpec: notification-system
- Created: 3 February 2011
- Contributors: GlenCampbell
<<TableOfContents()>>
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).
Event API
Events must be available per host and per server. The following API resources should be available:
/servers/{id}/events/hosts/{id}/events
| Method | Returns |
|GET
|
All events for the specified server or host |
|PUT
|
Not allowed |
|POST
|
Adds the event log data (specified in the POST body) to the events log for the server or host |
|DELETE
|
Clears the event log for the server or host |
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
- Suprfeedr uses a publisher callback mechanism. See also http://blog.superfeedr.com/pubsubhubbub-api/, where they describe the publisher callback extension in more detail.
- Discussion on access controls at the PSH website
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
TBD
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.
