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

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I just realized that while RDO now has a way to configure each service
separately with user defined configuration file, there is still one
limitation - a replacement for neutron.conf that contains lots of
options that are common to all services. I think we should also add a
new config-directory that would be loaded by *all* services.

I wonder what people think about its name. I think
/etc/neutron/conf.d/common is a good fit. Comments?

Ihar

On 04/13/2015 05:25 PM, Ihar Hrachyshka 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/ 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-decomposit
i
>
>> 
on
> 
> 
> [2]:
>> http://git.openstack.org/cgit/opensta

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

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nah, pointing --config-dir, either as one or as one of many arguments,
is just plain wrong. We want to have a way to set different
configuration values for different services, so merging all
configuration files into single pile of Neutron Configuration is not
something we should consider.

On 04/17/2015 11:17 PM, Kevin Benton wrote:
> 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
> mailto:ihrac...@redhat.com>> wrote:
> 
> 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
> 
> 
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 
>> mailto:ihrac...@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/ 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/opensta
c
>
>> 
k-
> 
> 
> neutron.spec#L602
>> 
>> 
ck-
> 
> 
> neutron.spec#L602>
>> [2]: 
>> https://github.com/openstack-packages/neutron/blob/f20-master/neutron
- -
>
>> 
l3
> 
> 
l3>
> 
> 
> -agent.service#L8
>> [3]: 
>> https://github.com/openstack-packages/neutron-vpnaas/blob/f20-master/
o
>
>> 
pe
> 
> 
> nstack-neutron-vpnaas.spec#L97
>> 
>> 
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, whe

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

[Kevin Benton]

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 
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
> > mailto:ihrac...@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/ 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
> >  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
> >  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 ques

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

[Ihar Hrachyshka]

-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
> mailto:ihrac...@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/ 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
> 
> 
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
> 
> 
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 

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

[Ihar Hrachyshka]

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

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 
> 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/ 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
 o

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

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/13/2015 10:08 PM, Matthew Thode wrote:
> 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

It
> 
would need to be explicitly described in documentation to rely on
it. I've sent a tiny patch to library documentation:

https://review.openstack.org/174883

> 
> 
> 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
>> mailto:ihrac...@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/ 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/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/
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

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

[Matthew Thode]

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  > 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/ 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 reasona

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

[Kevin Benton]

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 
wrote:

> -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/ 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]:
> > h

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

[Dimitri John Ledkov]

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

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.

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  wrote:
> -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/ 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 po

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

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/13/2015 05:42 PM, Matthew Thode wrote:
> We already do this somewhat in gentoo (at least for some daemon 
> initialization stuff) in /etc/conf.d/$DAEMON_NAME.conf.  Adding a 
> --config-dir option to that would be very simple.  Gentoo at least
> will also make the first --config-dir option (/etc/neutron)
> optional as well since we have some users that would like that
> level of separation.

I am not sure you want to pass the whole /etc/neutron as --config-dir
to your services since the directory may contain lots of files that
are irrelevant to the service in question. That's why RDO went with
per service directory + global /etc/neutron/neutron.conf.

> 
> In the mean time, do we install configs to those locations by
> default? I'm not seeing that as a subdir of etc in the neutron
> repo.
> 

If you ask about /etc/neutron/conf.d/, then no, so far it's RDO only.
As for l3 agent config dirs to load advanced services configuration
files on demand, we just link to appropriate configuration files
located in default /etc/neutron/... locations from there:

https://github.com/openstack-packages/neutron/blob/f20-master/openstack-
neutron.spec#L604

/Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBAgAGBQJVK+f7AAoJEC5aWaUY1u57OYAIAKHiX6BtE0MBflbMuGEQoQRM
O6EqNM8YVC/lBi+u5VvTv7l9UMATtV9aI8/EJs3LU6w/UMj8jl4fiITVJ4T/pWNg
rNb1TkePeM4ut7eCusEkqBupwYl0aCu/UQaDo2ZQ7zUUYgKIS1A39bkhTn9ihRQC
edumZt63UmTjEEgJTNflypf9BB+85uB3Li7AQJdu96q9dfZFpcswCBLVCs9kColj
FSeBpElrApcC2C2uSkPBIkaOkKexMWMYj1h4nsdQ6qGZmpFptpCa646jYYa9tYgP
zeTscF5JDY7lxqi71eHwNRfZCmSgQsR4pDfwA9UBuJDLKdLIOnIW+JMN9FyqNfY=
=4GT5
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Matthew Thode]

We already do this somewhat in gentoo (at least for some daemon
initialization stuff) in /etc/conf.d/$DAEMON_NAME.conf.  Adding a
--config-dir option to that would be very simple.  Gentoo at least will
also make the first --config-dir option (/etc/neutron) optional as well
since we have some users that would like that level of separation.

In the mean time, do we install configs to those locations by default?
I'm not seeing that as a subdir of etc in the neutron repo.

On 04/13/2015 10:25 AM, Ihar Hrachyshka 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/ 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.co

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

[Ihar Hrachyshka]

-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/ 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)
> Unsub

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

[Ben Nemec]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/13/2015 09:11 AM, 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.

This is essentially what tripleo does as well, for similar reasons I
believe.  For example, nova-api is configured like this:
https://github.com/openstack/tripleo-image-elements/blob/master/elements/nova-api/install.d/nova-source-install/80-nova-api#L15

Maybe a little hard to parse if you're not familiar with
os-svc-daemon, but essentially it's starting nova-api with
"--config-dir /etc/nova --config-dir /etc/nova/api" so we can
configure nova-api without stepping on any other service, and still
have common configs in /etc/nova.

AFAIK it has worked well for us, and it does seem like a more flexible
way to handle configs so +1 to doing it elsewhere too.

- -Ben

> 
> [1]: 
> https://blueprints.launchpad.net/neutron/+spec/core-vendor-decomposition
>
> 
[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/openstack-neutron.spec#L700
>
>  Regards, /Ihar
> 
> /Ihar
> 
> __
>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVAzIsAAoJEDehGd0Fy7uqwskIAIuZT9ORIXzqAA95ftRXSsNO
ehQn3JA3BQ/92D3DzTd6ADiV9JI7TjZCIzA+o+0NVs1gqMjyFNAOksdpnJKbqPxH
ToP4qhsR/ow3D2oM9dD2gIGLP/wNAOB6TFMSqwQhX/Oiu6ING06UmxW+TekA8eTq
OY9ODU1+9h0ejHZqAnhWzdsFB9s1OmL4qeJIuiJ4O3PuILYK2NaIZ5B3yO3r2bi5
PVQRa1lcROL5kzjULQGaA7tv

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

[Doug Hellmann]

On Fri, Mar 13, 2015, at 10:11 AM, Ihar Hrachyshka wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> 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).

The --config-dir option was added at the request of some of the folks
working on deployment automation (I don't remember if it was the puppet
folks, the chef folks, or both) because it's easier to add a file than
to modify one. 

So yes, if each driver or add-on or whatever uses a separate file *and
configuration section* for its overrides, oslo.config can just read all
of the files and merge them together. Only the options actually being
used by running code will be validated, so there's no harm in deploying
"extra" configuration files.

> 
> 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-decomposition
> [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/openstack-neutron.spec#L700
> 
> Regards,
> /Ihar
> 
> /Ihar
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iQEcBAEBAgAGBQJVAu/8AAoJEC5aWaUY1u57yx4H/0AE+8LH6wByyBQAGvcSU0i7
> 0BNThPS2sy0sPEHIZCH7OH3prAAyG0IFb2NNyHvMjTbVHPR+wjavsxPcAth09vrh
> rQgnSTA9IkdX2w1+M/vKu0QKUPNQrs5KVIchUatsoReeM9Mmrq6YqG56dEx33Emi
> FvpTb7B6V4EOvrCRp6TT4gOHOrHO5kwa62sXSFP8+IpzOcOKeO9XTFTC7PeKFtMi
> AHwjvpHjnOl8bNpTbGz5nVZkAT/XTv0TiiPIQF7NFPIkzlan4E/K04N8DIis5fdA
> P+8eDaEGDxsW4LYZ9AfITml3G0uVqcpiRIwwIL4f84ubQKjSARW8Roi1FwPSsbI=
> =gkZr
> -END PGP SIGNATURE-
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listin

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

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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-decomposition
[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/openstack-neutron.spec#L700

Regards,
/Ihar

/Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVAu/8AAoJEC5aWaUY1u57yx4H/0AE+8LH6wByyBQAGvcSU0i7
0BNThPS2sy0sPEHIZCH7OH3prAAyG0IFb2NNyHvMjTbVHPR+wjavsxPcAth09vrh
rQgnSTA9IkdX2w1+M/vKu0QKUPNQrs5KVIchUatsoReeM9Mmrq6YqG56dEx33Emi
FvpTb7B6V4EOvrCRp6TT4gOHOrHO5kwa62sXSFP8+IpzOcOKeO9XTFTC7PeKFtMi
AHwjvpHjnOl8bNpTbGz5nVZkAT/XTv0TiiPIQF7NFPIkzlan4E/K04N8DIis5fdA
P+8eDaEGDxsW4LYZ9AfITml3G0uVqcpiRIwwIL4f84ubQKjSARW8Roi1FwPSsbI=
=gkZr
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev