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

Dimitri John Ledkov dimitri.j.ledkov at intel.com
Mon Apr 13 17:47:15 UTC 2015


For Clear Linux* for Intel Architecture we do not allow to package
things in /etc, instead we leave /etc completely empty and for
user/admin modifications only.
Typically we achieve this by moving "sane distro defaults" to be
compiled in defaults, or read from alternative locations somewhere
under /usr.
This is similar to e.g. how udev reads from /usr/lib & /etc. (ditto
systemd units, XDG Freedesktop spec, etc.)

Integration wise, it helps a lot if there is a conf.d like directory
somewhere under /usr & under /etc, such that both "packaging/packages"
and user can integrate things.

I'll need to look more into this, but e.g. support for
/usr/share/neutron/conf.d/*.conf or
/usr/share/openstack/neutron/*.conf would be useful to us and other
distributions as well.

Shipping things in /etc is a pain on both dpkg & rpm based
distributions as config file handling is complex and has many corner
cases, hence in the past we all had to do transitions of "stock"
config from /etc -> /usr transitions (e.g. udev rules). Please keep
/etc for _only_ user created configurations and changes without any
"stock", "documentation", "defaults" shipped there.



ps sorry for loss of context, only recently subscribed, don't have
full access to the thread and hence the ugly top-post reply, sorry
about that.

On 13 April 2015 at 09:25, Ihar Hrachyshka <ihrachys at redhat.com> wrote:
> Hash: SHA1
> 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
> Version: GnuPG v2
> +lQKu9HXX/hEI0A1wVtpjXEsXiyUWlyZTBTYPmRXEH1nhhznCO5dRPtJ0I9N9NoZ
> CA04bdxnJll8PYp16+i9YCdCQoE9DSoT1Qr4JimMFA2ZVS4E0P3WP486s1tMmoaL
> mLKBPrm8Y0YGsJYOENG8aeMuNI16pjdWRYx9icxUdpD3lOZc/kzxbaBf595jIUUn
> VHGJCUTUBsI/0S0gCDe7B046JCFnDfxfza/WlCzHXOjZ+fPJCgl/+RzsjPJ7k4Q+
> Eu7JQEHMQ3tY0bR5DHuBseVmuRlfvztx7i6EdrWTvdm4LH5Q3QqdA0vHr6tZ/qk=
> =y8b1
> __________________________________________________________________________
> 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



Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.

More information about the OpenStack-dev mailing list