Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/13/2015 07:47 PM, Dimitri John Ledkov wrote:
> Hello,
> 
> 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.)

Some people may be used to having a configuration file with all
supported options mentioned, with descriptions, to edit. Though I
admire the direction your distribution chose for configuration. And
this is why RDO/neutron team feels that we should provide this
additional way of service configuration to our users.

> 
> 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.

I vote for /usr/share/neutron/conf.d/<service-name>

Where service name is e.g. 'server', 'l3-agent', 'dhcp-agent' etc.
That said, the file location is not intended to be modified by anyone
other than distribution, so it's not that important whether all
distributions are on the same page in this particular case. For
/etc/neutron/conf.d file structure, it's a lot more important.

> 
> 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.

Existing users won't buy the sentiment, so at least in RDO world, we
need to handle both old (neutron.conf) and new (conf.d/server/) ways
to configure our services.

If you start a new distribution, it's a bit different since you can
define more strict rules from the start while you haven't set
different expectations for your user base.

> 
> Regards,
> 
> Dimitri.
> 
> 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: 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/openstac
k-
>
> 
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/o
pe
>
> 
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-decompos
iti
>
>>>> 
on
>>>> 
>>>> 
> [2]:
>>>> http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/neutr
on#
>
>>>> 
n393
>>>> 
>>>> 
> [3]:
>>>> https://github.com/openstack-packages/neutron/blob/f20-master/neutr
on-
>
>>>> 
l3-agent.service#L8
>>>> 
>>>> 
> [4]: https://review.gerrithub.io/#/c/218562/
>>>> [5]: 
>>>> https://ask.fedoraproject.org/en/question/25722/what-are-rpmnew-fil
es/
>>>>
>>>>
>
>>>> 
[6]:
>>>> https://github.com/openstack-packages/neutron/blob/f20-master/neutr
on-
>
>>>> 
dist.conf
>>>> 
>>>> 
> [7]:
>>>> https://github.com/openstack-packages/neutron/blob/f20-master/opens
tac
>
>>>> 
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
>
>> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJVMRPcAAoJEC5aWaUY1u57WZwH/2Zsfq1oiBPPz3w1lB7nIVnO
Hr2p1WPNHRbkMqlRCGaXJ3unWhBt7b4PkZ60Q6EycdAHwHpAg1CUPJz0kMPwnnO9
YU9vsyla5LdifdbH4oMcIMlvvDp/PQIOUEQUYl4NdC3IyYHc7xx6kMCqMWrbX8kq
yStIxhRgqIlu/ro8QHla2nCIq0v3qyhs1gQhtcxuax9U1+gAMYgezz5XxVXE/PLC
vnSF8CqeuECNdyJI4plsB9T4QNlUlVss9iXAbUBPnmrKO5gQRKrRVFmxcCIxH9RX
VhbUEgJ/lHSB0moUWUqcEBR9NbOxl5qd+mqp55+C1CXN6z1jJjQ7pTT5qdZRQUA=
=nueB
-----END PGP SIGNATURE-----