Open Stack

Great! I was just worried that it was going to become one --config-dir
option that pointed to /etc/neutron or something.

On Fri, Apr 17, 2015 at 7:13 AM, Ihar Hrachyshka <ihrachys at redhat.com>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04/13/2015 09:45 PM, Kevin Benton wrote:
> > What is the order of priority between the same option defined in
> > two files with --config-dir?
>
> Should be alphabetically sorted, but it's not yet defined in
> documentation. I've sent a patch for this:
> https://review.openstack.org/174883
>
> >
> > 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.
>
> It's not actually an abuse, but behaviour that is guaranteed by public
> library documentation, and it's fine to rely on it.
>
> >
> > Will there still be the ability to do that with RDO?
>
> Nothing changes for users who do not want to use conf.d directory and
> instead store their configuration in upstream config files (like
> neutron.conf or l3_agent.ini). RDO/neutron only *extends*
> possibilities to configure services with the new conf.d feature.
>
> The order of configuration storages as they are currently loaded in
> RDO/neutron services is the same for all of them, and can be checked
> in any systemd service file:
>
> https://github.com/openstack-packages/neutron/blob/f20-master/neutron-me
> tadata-agent.service#L8
>
> The way it's defined there, conf.d beats all other configuration
> files. But if you don't buy the new approach, you just don't have any
> files inside the directory to beat your conventional configuration.
>
> >
> > 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/openstac
> k-
> >
> >
> neutron.spec#L602
> > <https://github.com/openstack-packages/neutron/blob/f20-master/opensta
> ck-
> >
> >
> 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
> > <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-decomposit
> i
> >
> >>
> 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
> #
> >
> >
> n393>
> >
> >
> > [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
> - -
> >
> >
> 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/opensta
> c
> >
> >>
> k-neutron.spec#L700
> > <https://github.com/openstack-packages/neutron/blob/f20-master/opensta
> c
> >
> >
> 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://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
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBAgAGBQJVMRUOAAoJEC5aWaUY1u57lysH/Arx93DCQCjTNJlE9nUvug0g
> 4LwY3QPpB1jhuOw6V2Zwl+PkAV3+UWEsvk+C5CmVEV2nJjd++gAeoEhc3Zsgu4Gf
> exvQoScrQfdw0tG32c/WEYmiSYvCWxRARkJV+9t60VQtB2W04S1IeCk8hh2+Wxk5
> j1VH6aq4br8GvjvJAC8OM5dHdFmDZwXG4zUzcdk+PAKs5I6CYL9LpWfRI3V4/b+g
> vzIS8v5/9qHP5rbKkFTvHKwohMf2UQF+psGeyYdpjJFnKMUdYa3RcCMe+KbdTKg+
> ARIP6h1xEOgDcHbzvl36JJ0gjE8dg6fxOZIOV3ZhZg3ch26VKAHUXOnG5aDYX94=
> =NI+S
> -----END PGP SIGNATURE-----
>
> __________________________________________________________________________
> 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
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150417/9bc52cfb/attachment.html>