Open Stack

Alex Schultz <ASCHULTZ at redhat.com> wrote:

> On Thu, Oct 13, 2016 at 3:27 AM, Thomas Bechtold <tbechtold at suse.com>  
> wrote:
>> On Tue, Oct 11, 2016 at 12:32:40PM -0600, Alex Schultz wrote:
>>> On Tue, Oct 11, 2016 at 1:39 AM, Thomas Bechtold <tbechtold at suse.com>  
>>> wrote:
>>>> Hi,
>>>>
>>>> On Mon, Oct 10, 2016 at 10:07:05AM -0600, Alex Schultz wrote:
>>>>> On Mon, Oct 10, 2016 at 5:03 AM, Thomas Bechtold <tbechtold at suse.com>  
>>>>> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> in the rpm-packaging project we started to package the services and  
>>>>>> are
>>>>>> currently discussing a possible schema for configuration files and
>>>>>> snippets used by the systemd .service files (but this would also  
>>>>>> affect
>>>>>> OCF resource agents).
>>>>>> This affects packagers, endusers and config management systems (Chef,
>>>>>> Puppet, Ansible, Salt, ...) so I want to discuss the proposal here on
>>>>>> the list.
>>>>>
>>>>> This also affects deployment tools so you may want to include tripleo,
>>>>> kolla, fuel as they are downstream consumers and may have their own
>>>>> assumptions about how services are launched.
>>>>
>>>> Done.
>>>>
>>>>>> Most services (at least for SUSE and RDO) are using a single config
>>>>>> (e.g. /etc/nova/nova.conf) when starting the service. Some services
>>>>>> (e.g. neutron services like neutron-l3-agent) use multiple config  
>>>>>> files.
>>>>>>
>>>>>> There are multiple problems with that approach:
>>>>>> - when using a config-mgmt-system, users may want to override a config
>>>>>> option (for a feature that is not yet supported) but the
>>>>>> config-mgmt-system will override the config later again.
>>>>>
>>>>> Just to chime in here from a puppet standpoint, this is not a problem
>>>>> because we provide a way for a user to add any extra options they wish
>>>>> using the provider so it always ends up in the correct configuration
>>>>> file.
>>>>
>>>> Does that also work if you need extra configuration files for 3rd party
>>>> plugins (e.g. neutron plugins) ? I guess you could just copy the 3rd
>>>> party config file content to the needed neutron config but that's ugly  
>>>> imo.
>>>
>>> Plugins also have their own .ini files and are handled differently.
>>> They get weird but we put the service configs in
>>> /etc/neutron/neutron.conf and agent configs get put in .ini files.
>>
>> So you put the config sections from the plugins into the neutron conf
>> and mix things, right?
>
> Specifically for neutron, yes the service configs for plugins get put
> in neutron.conf but I believe they are in their own section.  It seems
> not to have an issue with this.

Each third party component for neutron may ship its config file to load  
into neutron-server when the component is used. You cannot handle the use  
case of those plugins shipping their own config files without some  
config-dir based mechanism. The use case is not going away any time soon,  
because of decisions made by neutron team respective to pluggability;  
decisions that are drastically different from what some other projects,  
like nova, made, which makes solutions working for nova not necessarily  
applying for neutron.

The third party config file loading complexity is the original reason why  
--config-dir options were added to RDO neutron-server systemd unit files.

Ihar