Open Stack

>For the record, oslo.config already reads /etc/neutron/neutron.conf

Yeah, I think this is the only reason it even manages to get some of the
correct configuration (loading a core plugin at all).

>Also for the record, I consider not being able to load existing split configuration
files a regression.

+1. That would make an upgrade nightmare. In my earlier email I didn't mean
to imply that was the only way forward. I was just curious if it still
broke when everything was in one file.

On Tue, Sep 5, 2017 at 7:01 AM, Ihar Hrachyshka <ihrachys at redhat.com> wrote:

> On Mon, Sep 4, 2017 at 8:07 AM, Kevin Benton <kevin at benton.pub> wrote:
> > #2 would be preferable as well just because we have so many
> guides/distros
> > mentioning the different file locations. I'm not familiar with mod_wsgi
> > enough to know if it's possible.
> >
> > Another 3rd option may be to edit the oslo config constructor call when
> > using that entry point to add some well-known paths for additional config
> > files rather than only parsing 'sys.argv[1]'. For example, we could
> always
> > try to add /etc/neutron/plugin.ini to the list which we can document that
> > distros/deployment tools should always create or have a symbolic link to
> a
> > plugin-specific config (e.g. ml2_conf.ini).
>
> For the record, oslo.config already reads /etc/neutron/neutron.conf
> (and some other locations) when no arguments are passed:
>
> https://github.com/openstack/oslo.config/blob/master/oslo_
> config/cfg.py#L711-L739
>
> Also for the record, I consider not being able to load existing split
> configuration files a regression. We won't be able to move to the new
> operation mode unless we figure out how to load them. If mod_wsgi is
> not willing to bend their argv, a envvar could be a good option.
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170905/1c5a014e/attachment.html>