opt-out of certain notifications

[Steve Martinelli]

keystone currently support a lot of event notifications, just see http://docs.openstack.org/developer/keystone/event_notifications.html

It would be nice if there was a configuration option to allow users to opt-out of notifications they didn't care about.

This could be as simple as:

[notifications]
listen_group_create = True
listen_group_delete = True
listen_group_update = True
...
listen_authenticate_success = True

Or something more advanced.

Either way, each would have to be set to True by default.

[Fernando Diaz (diazjf)]

Hey Steve, how does something like this look:

notifications.py
------------------------

Add:
enabled_events = {}

which will read from the conf and eventually generate something like:

enabled_events = {
    "resource_type": {'user', 'group'},
    "operation": {ACTIONS.created}
}

and in:
def _create_cadf_payload(operation, resource_type, resource_id,
                         outcome, initiator):

we add:
if resource_type in enabled_events.get("resource_type") and \
                    operation in enabled_events.get("operation"):

to the top of the function.

[Steve Martinelli (stevemar)]

Hey Fernando,

The implementation can be done in a variety of ways and we can optimize as we review. I think the harder part here is setting up a way for user's to pick and choose which events they want to listen to.

Listing them out as booleans:

[notifications]
listen_group_create = True
listen_group_delete = True
listen_group_update = True
...
listen_authenticate_success = True

Have users add "event_type" strings in a multi-string option, the event types are well defined in the format: "event_type": "identity.<resource_type>.<operation>"

[notifications]
opt-in = "identity.user.created"

or maybe the flip, out-opt

[notifications]
opt-out = "authenticate.success"

These are just my ideas, propose a patch and let's see what ideas are kicked around!

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/253780

[David Stanek (dstanek)]

What is the problem with having too many? Is it too hard to ignore then, is there a performance issue or something else?

[Steve Martinelli (stevemar)]

@david, you touched on some of the issues. It can be information overload, and if you are logging these to events to logs instead of a message bus then unless you are in the business of buying hard drives, you will want some way to control what events are printed.

if logging to a message bus, then too many events can be hard to ignore. I'm still suggesting we keep them all enabled by default.

[Fernando Diaz (diazjf)]

I like the opt-out since I think most users would want all the notifications by default.

[David Stanek (dstanek)]

@Steve, I think this is probably a good feature to have, but having the 'why' details documented means that other won't have to guess too.

[Matt Fischer (mfisch)]

In addition to log space, many folks would like to not overload their rabbit servers (if using rabbit queues for this). If there's a problem with the consumer the queues can fill up and cause issues.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/253780
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=255685877ec54d1b9689b88cc5af8a5490d30c91
Submitter: Jenkins
Branch: master

commit 255685877ec54d1b9689b88cc5af8a5490d30c91
Author: Fernando Diaz <email address hidden>
Date: Fri Dec 4 22:23:15 2015 -0600

    Opt-out certain Keystone Notifications

    This patch will allow certain notifications for events in
    Keystone to be opted out. Opting out may be a desired way of
    doing this since most keystone deployers will likely like
    to by default have all audit traces.

    Change-Id: I86caf6e5f25cdd76121881813167c2144bf1d051
    Closes-Bug: 1519210

[Thierry Carrez (ttx)]

This issue was fixed in the openstack/keystone 9.0.0.0b3 development milestone.