[openstack-dev] [packaging][neutron] --config-dir vs. --config-file

Matthew Thode prometheanfire at gentoo.org
Mon Apr 13 15:42:04 UTC 2015

We already do this somewhat in gentoo (at least for some daemon
initialization stuff) in /etc/conf.d/$DAEMON_NAME.conf.  Adding a
--config-dir option to that would be very simple.  Gentoo at least will
also make the first --config-dir option (/etc/neutron) optional as well
since we have some users that would like that level of separation.

In the mean time, do we install configs to those locations by default?
I'm not seeing that as a subdir of etc in the neutron repo.

On 04/13/2015 10:25 AM, Ihar Hrachyshka wrote:
> Hi,
> RDO/master (aka Delorean) moved neutron l3 agent to this configuration
> scheme, configuring l3 (and vpn) agent with --config-dir [1][2][3].
> We also provided a way to configure neutron services without ever
> touching a single configuration file from the package [4] where each
> service has a config-dir located under
> /etc/neutron/conf.d/<service-name> that can be populated by *.conf
> files that will be automatically read by services during startup.
> All other distributions are welcome to follow the path. Please don't
> introduce your own alternative to /etc/neutron/conf.d/... directory to
> avoid unneeded platform dependent differences in deployment tools.
> As for devstack, it's not really feasible to introduce such a change
> there (at least from my perspective), so it's downstream only.
> [1]:
> https://github.com/openstack-packages/neutron/blob/f20-master/openstack-
> neutron.spec#L602
> [2]:
> https://github.com/openstack-packages/neutron/blob/f20-master/neutron-l3
> -agent.service#L8
> [3]:
> https://github.com/openstack-packages/neutron-vpnaas/blob/f20-master/ope
> nstack-neutron-vpnaas.spec#L97
> [4]: https://review.gerrithub.io/#/c/229162/
> Thanks,
> /Ihar
> On 03/13/2015 03:11 PM, Ihar Hrachyshka wrote:
>> Hi all,
>> (I'm starting a new [packaging] tag in this mailing list to reach
>> out people who are packaging our software in distributions and
>> whatnot.)
>> Neutron vendor split [1] introduced situations where the set of
>> configuration files for L3/VPN agent is not stable and depends on
>> which packages are installed in the system. Specifically,
>> fwaas_driver.ini file is now shipped in neutron_fwaas tarball
>> (openstack-neutron-fwaas package in RDO), and so
>> --config-file=/etc/neutron/fwaas_driver.ini argument should be
>> passed to L3/VPN agent *only* when the new package with the file is
>> installed.
>> In devstack, we solve the problem by dynamically generating CLI
>> arguments list based on which services are configured in
>> local.conf [2]. It's not a viable approach in proper distribution
>> packages though, where we usually hardcode arguments [3] in our
>> service manifests (systemd unit files, in case of RDO).
>> The immediate solution to solve the issue would be to use
>> --config-dir argument that is also provided to us by oslo.config
>> instead of --config-file, and put auxiliary files there [4] (those
>> may be just symbolic links to actual files).
>> I initially thought to put the directory under /etc/neutron/, but
>> then realized we may be interested in keeping it out of user sight
>> while it only references stock (upstream) configuration files.
>> But then a question arises: whether it's useful just for this
>> particular case? Maybe there is value in using --config-dir outside
>> of it? And in that case, maybe the approach should be replicated to
>> other services?
>> AFAIU --config-dir could actually be useful to configure services.
>> Now instead of messing with configuration files that are shipped
>> with packages (and handling .rpmnew files [5] that are generated on
>> upgrade when local changes to those files are detected), users (or
>> deployment/installation tools) could instead drop a *.conf file in
>> that configuration directory, being sure their stock configuration
>> file is always current, and no .rpmnew files are there to manually
>> solve conflicts).
>> We can also use two --config-dir arguments, one for stock/upstream
>> configuration files, located out of /etc/neutron/, and another one
>> available for population with user configuration files, under
>> /etc/neutron/. This is similar to how we put settings considered to
>> be 'sane distro defaults' in neutron-dist.conf file that is not
>> available for modification [6][7].
>> Of course users would still be able to set up their deployment the
>> old way. In that case, nothing will change for them. So the
>> approach is backwards compatible.
>> I wonder whether the idea seems reasonable and actually useful for
>> people. If so, we may want to come up with some packaging
>> standards (on where to put those config-dir(s), how to name them,
>> how to maintain symbolic links inside them) to avoid more work for
>> deployment tools.
>> [1]:
>> https://blueprints.launchpad.net/neutron/+spec/core-vendor-decompositi
> on
> [2]:
>> http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/neutron#
> n393
> [3]:
>> https://github.com/openstack-packages/neutron/blob/f20-master/neutron-
> l3-agent.service#L8
> [4]: https://review.gerrithub.io/#/c/218562/
>> [5]:
>> https://ask.fedoraproject.org/en/question/25722/what-are-rpmnew-files/
> [6]:
>> https://github.com/openstack-packages/neutron/blob/f20-master/neutron-
> dist.conf
> [7]:
>> https://github.com/openstack-packages/neutron/blob/f20-master/openstac
> k-neutron.spec#L700
>>  Regards, /Ihar
>> /Ihar
>> ______________________________________________________________________
> ____
> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Matthew Thode

-- Matthew Thode (prometheanfire)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150413/eab386b3/attachment.pgp>

More information about the OpenStack-dev mailing list