On Wed, Oct 19, 2016 at 11:07 PM, Joshua Harlow <harlo...@fastmail.com> wrote:
> Matt Riedemann wrote: > >> 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. >> >> > A valid concern IMHO, seems like we might want a isEnabledFor() on the > Notifier class in https://github.com/openstack/o > slo.messaging/blob/master/oslo_messaging/notify/notifier.py#L175 (I am > assuming here that the underlying drivers can even provide the knowledge to > know that, which may or may not be a big assumption?) > > -Josh +1. I can see this being useful. In ironic, we've managed to avoid the issue so far, but notification is still in its infancy (< 1 month old) and as it grows I think we will have to deal with this too. Ironic also has a [default]notification_level config option [1]; do you think that there will be a similar config option in oslo instead? --ruby [1] https://github.com/openstack/ironic/blob/a67facf208289b8bef3d7a8189e707d9d0ef6b9f/etc/ironic/ironic.conf.sample#L108-L112
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev