[Openstack] Notifications proposal

George Reese george.reese at enstratus.com
Tue May 10 04:17:29 UTC 2011


I think notifications need to be kept really simple. I put out a proposal a few months ago at:

http://broadcast.oreilly.com/2011/04/proposal-for-cloud-state-notifications.html

Let the subscribers do any heavy lifting. Just provide them enough information that they can make the right requests.

-George

On May 9, 2011, at 10:58 PM, Jorge Williams wrote:

> 
> On May 9, 2011, at 6:39 PM, Matt Dietz wrote:
> 
>> Jorge,
>> 
>>    Thanks for the feedback!
>> 
>>    Regarding the message format, we actually don't need the unique id in the generic event format because that's implementation specific. The external publisher I've implemented actually does all of the pubsubhubbub specific heavy lifting for you. The idea behind keeping this system simple at the nova layer is allowing people to implement anything they'd like, such as emails or paging. 
> 
> I guess, I'm not seeing the whole picture.  So these are internal messages? Will they cross service boundaries / zones?  I'm sorry I missed the conversation at the summit :-) Is there a blueprint I should be reading? 
> 
>> 
>> For categories, were you considering this to be a list? Could you give an example of an event that would span multiple categories?
>> 
> 
> From an Atom perspective, I suppose anything a client might want to key in on or subscribe to may be a category.  So "create" may be a category -- a billing layer may key in on all create messages and ignore others. "compute" may also be a category -- you can aggregate messages from other services so It'd be nice for messages from compute to have their own category.  To my knowledge, atom doesn't have the concept of priority so "WARN" may also be a category.  I suppose if these are internal messages an external publisher can split the event_type and priority into individual categories.
> 
>> Finally, I can make the changes to the timestamp. This as just a hypothetical example, anyway. 
>> 
> 
> Okay cool, thanks Matt.
> 
>> 
>> 
>> On May 9, 2011, at 6:13 PM, "Jorge Williams" <jorge.williams at rackspace.com> wrote:
>> 
>>> 
>>> On May 9, 2011, at 5:20 PM, Matt Dietz wrote:
>>> 
>>>> Message example:
>>>> 
>>>>     { 'publisher_id': 'compute.host1',
>>>>       'timestamp': '2011-05-09 22:00:14.621831',
>>>>       'priority': 'WARN',
>>>>       'event_type': 'compute.create_instance',
>>>>       'payload': {'instance_id': 12, ... }}
>>>> 
>>>> There was a lot of concern voiced over messages backing up in any of the queueing implementations, as well as the intended priority of one message over another. There are couple of immediately obvious solutions to this. We think the simplest solution is to implement N queues, where N is equal the number of priorities. Afterwards, consuming those queues is implementation specific and dependent on the solution that works best for the user.
>>>> 
>>>> The current plan for the Rackspace specific implementation is to use PubSubHubBub, with a dedicated worker consuming the notification queues and providing the glue necessary to work with a standard Hub implementation. I have a very immature worker implementation at https://github.com/Cerberus98/yagi if you're interested in checking that out. 
>>> 
>>> 
>>> Some thoughts:
>>> 
>>> In order to support PubSubHubBub you'll also need each message to also contain a globally unique ID.  It would also be nice if you had the concept of categories.  I realize you kinda get that with the event type "compute.create_instance" but there are always going to be messages that may belong to multiple categories. Also, ISO timestamps with a T :  "2011-05-09T22:00:14.621831" are way more interoperable -- I would also include a timezone designator Z for standard time 2011-05-09T22:00:14.621831Z -- otherwise some implementation assume the local timezone.
>>> 
>>> -jOrGe W.
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

--
George Reese - Chief Technology Officer, enStratus
e: george.reese at enstratus.com    t: @GeorgeReese    p: +1.207.956.0217    f: +1.612.338.5041
enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com
To schedule a meeting with me: http://tungle.me/GeorgeReese

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110509/91cc221a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4395 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110509/91cc221a/attachment.bin>


More information about the Openstack mailing list