Open Stack

The loading seems to me in a sorted order, so we can do 1.conf 2.conf etc.

https://github.com/openstack/oslo.config/blob/1.9.3/oslo_config/cfg.py#L1265-L1268


On 04/13/2015 02:45 PM, Kevin Benton wrote:
> What is the order of priority between the same option defined in two
> files with --config-dir? 
> 
> With '--config-file' args it seemed that it was that the latter ones
> took priority over the earlier ones. So an admin previously had the
> ability to abuse that by putting all of the desired global settings in
> one of the earlier loaded configs and then add some node-specific
> overrides to the ones loaded later.
> 
> Will there still be the ability to do that with RDO?
> 
> On Mon, Apr 13, 2015 at 8:25 AM, Ihar Hrachyshka <ihrachys at redhat.com
> <mailto: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/openstack-
> neutron.spec#L602
> <https://github.com/openstack-packages/neutron/blob/f20-master/openstack-%0Aneutron.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
> <https://github.com/openstack-packages/neutron-vpnaas/blob/f20-master/ope%0Anstack-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
> <http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/neutron#%0An393>
> 
> 
> [3]:
>> https://github.com/openstack-packages/neutron/blob/f20-master/neutron-
> l3-agent.service#L8
> <https://github.com/openstack-packages/neutron/blob/f20-master/neutron-%0Al3-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
> <https://github.com/openstack-packages/neutron/blob/f20-master/openstac%0Ak-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://OpenStack-dev-request@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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> -- 
> Kevin Benton
> 
> 
> __________________________________________________________________________
> 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/ed0c2b5e/attachment.pgp>