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-requ...@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
__________________________________________________________________________
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
