Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
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
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJVK9/9AAoJEC5aWaUY1u57phQIAJIy4Q/cnINfS5UPDSv65I59
+lQKu9HXX/hEI0A1wVtpjXEsXiyUWlyZTBTYPmRXEH1nhhznCO5dRPtJ0I9N9NoZ
CA04bdxnJll8PYp16+i9YCdCQoE9DSoT1Qr4JimMFA2ZVS4E0P3WP486s1tMmoaL
mLKBPrm8Y0YGsJYOENG8aeMuNI16pjdWRYx9icxUdpD3lOZc/kzxbaBf595jIUUn
VHGJCUTUBsI/0S0gCDe7B046JCFnDfxfza/WlCzHXOjZ+fPJCgl/+RzsjPJ7k4Q+
Eu7JQEHMQ3tY0bR5DHuBseVmuRlfvztx7i6EdrWTvdm4LH5Q3QqdA0vHr6tZ/qk=
=y8b1
-----END PGP SIGNATURE-----