Authors

Public Pad

Latest text of pad notifications
Saved Sept 2, 2011
 
Burrow Proposal
------------------------
There seem to be at least two proposals for the same functionality, one using PuSH, another using Amazon SNS-style notifications. I would like to propose using Burrow as a least common denominator which can power both of these interfaces along with others. Burrow provides both one-to-one and fanout queue functioality, and the fanout method could be used as an intermediate queue for workers that publishing atom feeds, nagios checks, etc. It can also be consumed directly using any HTTP or Burrow client. For example:
 
* Nova instance /<account>/servers/1 produces an event
* A Nova event plugin for Burrow calls create_message(<account>, 'server-notifications', <unique message  id>) to insert a message. It could also be inserted into multiple queues for different notifications (for example administrator and subscribed user tracking).
* Multiple queue readers receive this event:
  - Direct readers subscribed to /<account>/server-notifications/ (using openstack-auth for access control)
  - AJAX application using Burrow directly.
  - A worker may pull events and publish them via PuSH/RSS/etc.
  - A Nagios server could poll for new events.
  - Another worker could send email notifications.
  - We can create SQS/SNS compatible APIs into Burrow if that is needed.
* Messages that are inserted get deleted automatically after some TTL.
 
A similar setup could be used to statistics as well, with workers aggregating and storing statistics for later consumption (RRD, logs, etc).
 
PF Labs Notification and Watch implementation
https://code.launchpad.net/~ntt-pf-lab/nova/nova-nwatcher-sns
We have DEMO.
 
Amazon CloudWatch
API Version: 2010-08-01
http://docs.amazonwebservices.com/AmazonCloudWatch/2010-08-01/APIReference/
Limitation for current implemantation
 
DescribeAlarmHistory
HistoryItemType, MaxRecords, NextToken is not used for searching.
 
DescribeAlarms
ActionPrefix, AlarmNamePrefix, AlarmNames.member.N, MaxRecords, Nextoken StateValue is not used for searching.
 
ListMetrics
Dimensions.member.N, MetricName, Namespace, NextToken is not used.
 
Amazon Simple Notification Service (SNS)
API Version: 2010-03-31
http://docs.amazonwebservices.com/sns/2010-03-31/api/
 
Limitation for current implemantation
CreateTopic
 
For ARN(AmazonCloudWatchResourceNumber), we use nova project id instead of namespace of Amazon.
 
arn:aws:<vendor>:<region>:<namespace>:<relative-id>
Example: arn:aws:sns:us-east-1:401808652880:test
 
arn:aws:sns:<region>:<project_id>:<relative-id>
Example: arn:aws:sns:nova:admin:test
 
GetTopicAttributes
Current implemantation has no access control,
so response value has no policy value.
 
ListSubscriptions
NextToken is not used for searching.
 
ListTopics
NextToken is not used for searching.
 
Subscribe
Only http,email are supported
 
SetTopicAttributes
Only displayName can be modified.
 
Compatible with 
 
Discussion Point
1. boto libraries
current version of boto in nova didn't support notification and cloudwatch
 -> we implemanted patched version, and we set it contrib directoriy.
 
2. How to store watch logs?
Current implemantation stores log data for nova database (SQLLite or Mysql).
We need some abstucted API for KVS or HDFS (FS for hadoop?)
 
Need to define format for messages. 
* event type (important, needs to be codified) / Priority
* publisher ID (zone, host, instance)
* date/time
* context (user, group, tenant)
* value/content
 
Continue metrics discussion on mailing list with examples. 
 
Consensus: JSON dict with names that match, as closely as possible, the Python names for events and objects.