Open Stack

On 10/20/2016 05:07 AM, Joshua Harlow 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/oslo.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?)

Would this eventually lead to the ability to turn off notification per 
event? If so, we're going to get very detailed configuration settings 
very quickly...

-jay