Open Stack

On 10/20/2016 4:19 AM, Jay Pipes wrote:
> 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

I'm not asking for that, I'm just asking for what Josh pointed out 
above, which is basically oslo_messaging.notifier.isEnabled() or 
whatever. The isEnabledFor granularity probably made you think of 
different events getting filtered on/off, but that's not what we want. 
Just is the notification framework setup at all - maybe isEnabledFor 
would just take a parameter for the notification queue, so nova only 
cares about the nova notifications.

-- 

Thanks,

Matt Riedemann