[openstack-dev] [nova] Performance concerns over all the new notifications

Matt Riedemann mriedem at linux.vnet.ibm.com
Thu Oct 20 01:49:27 UTC 2016


There are a lot of specs up for review in ocata related to adding new 
versioned notifications for operations that we didn't have notifications 
on before, like CRUD operations on resources like flavors and server groups.

We've got a lot of legacy notifications for server actions, like 
server.pause.start and server.pause.end. Those are pretty simple.

The thing that has me concerned about the CRUD operation notifications 
on resources is the extra DB query overhead to create the payloads which 
might not even get sent out.

For example, I was reviewing this spec about adding notifications for 
CRUD ops on server groups:

https://review.openstack.org/#/c/375316/

Looking at the code for InstanceGroup, when a member is added to or 
removed from the group, the hosts field implicitly changes, but to 
calculate the hosts field we have to get all of the instances (members) 
in the group and then built the list of instance.host values.

This is probably less of an issue if the server group object in scope 
already has the hosts field set, but if it doesn't and we're 
constructing it just for the notification, that's extra DB and RPC 
overhead - and notifications might not even be setup.

I was thinking about it like logging details at debug level. If I need 
to build some large object or get some data for debugging something 
that's not in scope, I'd wrap that in a conditional:

   if LOG.isEnabledFor(logging.DEBUG):
       LOG.debug('gimme da deets: %s', self.build_da_deets())

But do we have anything like that for notifications? Basically, tell me 
if I should even bother building payloads for notifications.

-- 

Thanks,

Matt Riedemann




More information about the OpenStack-dev mailing list