Open Stack

On Wed, Oct 19, 2016 at 11:07 PM, Joshua Harlow <harlowja at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161020/3922c77f/attachment.html>