[openstack-dev] [neutron][puppet] mod_wsgi support (pike bug?)
kevin at benton.pub
Tue Sep 5 15:01:28 UTC 2017
>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
> > 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'. For example, we could
> > 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
> > 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:
> 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.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev