Jump to: navigation, search

Difference between revisions of "MelangeNotifications"

m (Text replace - "NovaSpec" to "NovaSpec")
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
__NOTOC__
+
 
* '''Launchpad Entry''': [[NovaSpec]]:melange-notifications
+
* '''Launchpad Entry''': NovaSpec:melange-notifications
 
* '''Created''':
 
* '''Created''':
 
* '''Contributors''': troy-toman  
 
* '''Contributors''': troy-toman  
Line 8: Line 8:
 
This spec is derived directly from the Nova Notifications System spec. [[NotificationSystem]]
 
This spec is derived directly from the Nova Notifications System spec. [[NotificationSystem]]
  
Melange has a need to make notifications available to users in as close to a real-time manner as is feasible. The proposed solution is to implement a [[PubSubHubbub]] (PSH) mechanism where Melange 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.  
+
Melange has a need to make notifications available to users in as close to a real-time manner as is feasible. The proposed solution is to simply create the notifications on the message queue, and then Yagi (or some other adapter) can publish them as needed. 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/.
 
 
 
Melange should not  implement a hub from scratch, since there are several reference hubs available. In most cases, it will just talk to the same hub that would be set up for Nova. 
 
  
 
== Release Note ==
 
== Release Note ==
Line 36: Line 32:
 
# Services or components that produce notifications MUST make those notifications available in Atom 1.0 format.
 
# 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.
 
# 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).
 
 
# The <atom:content> element SHOULD contain structured data in a standard format (technically, this is a requirement on the service producing the notification; however, the notification service should validate that the <content type=""> is valid).  
 
# The <atom:content> element SHOULD contain structured data in a standard format (technically, this is a requirement on the service producing the notification; however, the notification service should validate that the <content type=""> is valid).  
  
 
=== Event API ===
 
=== Event API ===
  
Events must be available for the key resources in Melange including blocks and tenants. The following API resources should be available:
+
Following the Nova convention, there will not be an API for events. Events will be available in the queue only.
 
 
<code><nowiki>/ip_blocks/{id}/events</nowiki></code><<BR>>
 
<code><nowiki>/tenants/{id}/events</nowiki></code>
 
 
 
{| border="1" cellpadding="2" cellspacing="0"
 
|  '''Method'''
 
|  '''Returns'''
 
|-
 
|<code><nowiki>|GET</nowiki></code>
 
|  All events for the specified entity
 
|-
 
|<code><nowiki>|PUT</nowiki></code>
 
|  Not allowed
 
|-
 
|<code><nowiki>|POST</nowiki></code>
 
|  Adds the event log data (specified in the POST body) to the events log for the specified entity
 
|-
 
|<code><nowiki>|DELETE</nowiki></code>
 
|  Clears the event log for the specified entity 
 
|}
 
 
 
An Atom aggregation/archive service must be provided at the system-wide level.
 
  
 
=== Hub Development ===
 
=== Hub Development ===
  
Melange 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:
+
We are not using hubs in the notification implementation
 
 
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. Melange should implement one of those systems on top of its chosen hub.
 
 
 
* [https://docs.google.com/a/xlerb.com/document/pub?id=1HrVmSCQM2r5bCnQk5uZPbhH0sGVHHFOGhxJ0thoKEO8&ndplr=1&pli=1 PSH for Private Feeds]
 
* Suprfeedr uses a [http://blog.superfeedr.com/PubSubHubbub/Spec/Extension/publisher-callback-extension/ publisher callback mechanism]. See also http://blog.superfeedr.com/pubsubhubbub-api/, where they describe the publisher callback extension in more detail.
 
* [http://groups.google.com/group/pubsubhubbub/browse_thread/thread/96b6b3ead71dd1ed Discussion on access controls at the PSH website]
 
 
 
The implementor should choose one of these methods that best fits the current Melnage authentication pattern(s).
 
  
 
----
 
----
 
[[Category:Spec]]
 
[[Category:Spec]]

Latest revision as of 23:31, 17 February 2013

  • Launchpad Entry: NovaSpec:melange-notifications
  • Created:
  • Contributors: troy-toman

Summary

This spec is derived directly from the Nova Notifications System spec. NotificationSystem

Melange has a need to make notifications available to users in as close to a real-time manner as is feasible. The proposed solution is to simply create the notifications on the message queue, and then Yagi (or some other adapter) can publish them as needed. Clients subscribe to the appropriate notifications to receive updates when their are notifications waiting.

Release Note

Rationale

We need to be consistent in how we push notifications with the other OpenStack components (notably Glance and Nova.)

User stories

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

As a Melange 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

  1. Services or components that produce notifications MUST make those notifications available in Atom 1.0 format.
  2. There MUST be a central configuration setting that defines zero or more hubs to be used for notifications.
  3. The <atom:content> element SHOULD contain structured data in a standard format (technically, this is a requirement on the service producing the notification; however, the notification service should validate that the <content type=""> is valid).

Event API

Following the Nova convention, there will not be an API for events. Events will be available in the queue only.

Hub Development

We are not using hubs in the notification implementation