Matt Kassawara <mkassawara gmail com> wrote:
I agree that *-paste.ini files should remain static. Keystone contains the only one that we need to edit (for security reasons) and the patch to move this configuration out of keystone-paste.ini needs attention from the keystone project. As for the installation guide, I prefer to unify the documentation for editing keystone-paste.ini for all distributions. Furthermore, our audience (mostly new users) likely feels more confident about editing files that reside in a less "intimidating" location such as /etc/$service.Best I can tell, neutron (and all other services) separate "mandatory" message queue access (the 'rpc_backend' option) from notification access because the latter only pertains to deployments with a consumer for notifications such as ceilometer. Without a consumer, notification queues pile up and lead to stability problems. Hence, the 'notification_driver' option defaults to a blank value that essentially disables such notifications. The upstream configuration file comments this option out and installation guide doesn't explicitly configure it which means neutron uses the value of 'notification_driver' from the neutron-dist.conf file and sends notifications to a queue without a consumer. While I'm thinking about it, I'm trying to determine the source of a memory leak (or strange increase in consumption) in my RDO Liberty environment (and prior releases) and should try disabling the notification driver. In comparison, my Ubuntu Liberty environment containing the same services and virtual resources has stable memory usage.
Do you use DHCP agent from neutron? I think it requires notification driver to be enabled.
Description: Message signed with OpenPGP using GPGMail