[Rdo-list] [OpenStack-docs] [install-guide] Status of RDO
Matt Kassawara
mkassawara at gmail.com
Wed Nov 4 13:46:46 UTC 2015
Yes.
On Wed, Nov 4, 2015 at 2:21 AM, Ihar Hrachyshka <ihrachys at redhat.com> wrote:
> Matt Kassawara <mkassawara at 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.
>
> Ihar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20151104/4a38ab18/attachment.html>
More information about the dev
mailing list