keystone notification should use different topic for CADF and normal notificaiton

[Haneef Ali]

Keystone uses same topic for both normal notificaiton and audit. Ideally both should be in different topic. Both has different security/persistence requirement

[Morgan Fainberg (mdrnstm)]

This might be mostly irrelevant moving forward in light of the plan to move 100% to CADF notifications, deprecating the old notifications over a period of time. See: http://specs.openstack.org/openstack/keystone-specs/specs/kilo/cadf-everywhere.html

[Steve Martinelli (stevemar)]

this might not be that easy, since it's setup in oslo.messaging:

https://github.com/openstack/keystone/blob/0e9aefe73baf06997067e06f2485b883a1c29e6c/keystone/notifications.py#L220

and

https://github.com/openstack/keystone/blob/0e9aefe73baf06997067e06f2485b883a1c29e6c/keystone/common/config.py#L933

[Haneef Ali (haneef)]

I agree the way config is done makes it difficult to have different options for different topics.

I haven't tried it but notifier has audit method which can be used to send notification with *.audit routing key
http://docs.openstack.org/developer/oslo.messaging/notifier.html

Using CADF may or may not be a good option. CADF payload is big and I don't think any service is interested in auth event which is a major chunk

Assuming swift, nova , glance are interested in project.deleted event, the only way we can do with the current setup is to configure multiple topics in keystone.conf.

(i.e) notificatontopics = swiftnotification, glancenotification, novanotification.

Now we have 3 copies of payload for every event in queue. I believe more and more services will be interested in project events and we will be having more copies If one of the consumer is down, it is going to stay in queue and eat lot of memory

Am I missing something? What is the recommended way of deploying , if 5 services are interested in project.deleted event