Hey Phil! The notifications have been quite stable for some time now. I'm adding some basic protocol tweaks (supporting the compute.instance.update messages and fixing some confusion in the instance_uuid naming), but also making larger changes:
1. StackTach can now be used across cells in a single large deployment (very cool to watch) 2. Matt Sherbourne added some great performance/stability improvements to the worker 3. A new cmdline tool "stacky" that is more approachable to operators/admins (allows sed/grep/less/tail support) 4. New Timing tables for pre-computing important operations like compute.run_instance 5. A new KPI option that computes operation time all the way from API request to Service fulfillment (slick) 6. Integration with error notifications (api 500's and service errors) so we can easily spot failed operations. (I recently added a middleware hook to notify on api faults) It's turning into a pretty powerful debugging tool, but I can see it evolving into something larger. I'll be doing a lightning talk on all the changes at the summit. -S ________________________________________ From: Day, Phil [philip....@hp.com] Sent: Wednesday, October 10, 2012 4:47 AM To: Sandy Walsh Subject: RE: Versioning for notification messages Hi Sandy, Are you making changes to StackTach to keep up with the notification system, or changes to the notification system to make StackTach even better ? Cheers, Phil -----Original Message----- From: Sandy Walsh [mailto:sandy.wa...@rackspace.com] Sent: 09 October 2012 18:37 To: Day, Phil; openstack@lists.launchpad.net (openstack@lists.launchpad.net) (openstack@lists.launchpad.net) Subject: RE: Versioning for notification messages While I think the idea has merit, it's going to be a tough thing to version. (I'm neck deep in the notifications right now making a major revision to StackTach) We'd have to version the context, the instance state dictionary, the cpu info and the related payloads for each type of message since each component comes from different, already-existing, systems. (as opposed to the notification being responsible for the entire payload itself) Lots of ramifications. -S From: openstack-bounces+sandy.walsh=rackspace....@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace....@lists.launchpad.net] on behalf of Day, Phil [philip....@hp.com] Sent: Tuesday, October 09, 2012 2:07 PM To: openstack@lists.launchpad.net (openstack@lists.launchpad.net) (openstack@lists.launchpad.net) Subject: [Openstack] Versioning for notification messages Hi Folks, What do people think about adding a version number to the notification systems, so that consumers of notification messages are protected to some extent from changes in the message contents ? For example, would it be enough to add a version number to the messages - or should we have the version number as part of the topic itself (so that the notification system can provide both a 1.0 and 1.1 feed), etc ? Phil _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
