Open Stack

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.
>

Also at what point is the notification system actually the equivalent of 
the database transaction log (just something to ask/think about). If 
every CRUD operation is doing notifications, it sorta feels like it is 
nearly just the same...

-Josh