Expanding on my other email. We could alter the oslo.config constructor call to pass in file paths from environmental variables as well. Maybe that's the easiest path forward since it would just be a change from sys.argv to the env vars.
On Mon, Sep 4, 2017 at 8:04 AM, Mohammed Naser <mna...@vexxhost.com> wrote: > On Mon, Sep 4, 2017 at 10:40 AM, Mohammed Naser <mna...@vexxhost.com> > wrote: > > On Mon, Sep 4, 2017 at 9:01 AM, Kevin Benton <ke...@benton.pub> wrote: > >> Yes, unfortunately I didn't make it back to the patch in time to adjust > >> devstack to dump all of the configuration into one file (instead of > >> /etc/neutron/neutron.conf /etc/neutron/plugins/ml2.conf etc). I did test > >> locally with my dev environment around the time that RPC server patch > went > >> in, but there may have been a regression since it went in since it's not > >> tested as Matt pointed out. > >> > > > > I've added Puppet into this because I think we would have to take a > > decision regarding this. The reason behind the fact that we've always > > used the two configuration files is because distributions which ship > > packages actually provide 2 configuration files. > > > > We use a configuration resource called `neutron_plugin_ml2` which > > configures things always in `/etc/neutron/plugins/ml2/ml2_conf.ini`. > > > > In the case of Ubuntu/Debian based systems, we update > > `/etc/default/neutron-server` to point the plugin configuration to > > `/etc/neutron/plugin.ini` and then we ensure that the file is a > > symbolic link to `/etc/neutron/plugins/ml2/ml2_conf.ini`. > > > > Now, we have two options in my mind (and I am open for others): > > > > 1) Configure plugins entirely inside `neutron.conf` > > This option would solve our issue but introduce another one. I > > believe that the order in the start commands would mean that the later > > configuration files (in this case, the plugin.ini) would have priority > > over the `neutron.conf` causing an inconsistency, I don't think this > > is possible. However, we can work around this by ensuring that the > > plugin.ini file is empty. However, we will be introducing service > > restarts for no reason with that change which can be very confusing > > for the user as to why configuration is moving. > > > > 2) Figure out a way to pass 'args' via WSGI? > > I'm not sure if this is entirely possible at all. But, could there be > > a way that we can pass a list of configuration files in the mod_wsgi > > configuration? This would make it the most transparent fix without > > having to adjust all of the configuration files and bend against the > > set configuration paths of the distro. > > I did a bit more research and unfortunately it looks like this option > is not possible (at least with mod_wsgi): > > https://github.com/GrahamDumpleton/mod_wsgi/blob/master/src/ > server/wsgi_interp.c#L546-L561 > > mod_wsgi sets the content of sys.argv to ["mod_wsgi"] only. > Environment variables are still a possibility. > > > I'd be more than happy to hear any other ideas regarding this > > solution. I would love to implement #2 if it is somehow possible > > (environment variables, maybe?) but #1 would work but be very messy > > for operators and users. > > > >> > >> It appears that puppet is still spreading the config files for the > server > >> into multiple locations as well[1]. Does it inherit that logic from > >> devstack? Because that will need to be changed to push all of the > relevant > >> server config into one conf. > >> > >> 1. > >> http://logs.openstack.org/82/500182/3/check/gate-puppet-open > stack-integration-4-scenario004-tempest-ubuntu-xenial/ > 791523c/logs/etc/neutron/plugins/ > >> > >> On Sun, Sep 3, 2017 at 12:03 PM, Mohammed Naser <mna...@vexxhost.com> > wrote: > >>> > >>> On Sun, Sep 3, 2017 at 3:03 PM, Mohammed Naser <mna...@vexxhost.com> > >>> wrote: > >>> > On Sun, Sep 3, 2017 at 2:20 PM, Matthew Treinish < > mtrein...@kortar.org> > >>> > wrote: > >>> >> On Sun, Sep 03, 2017 at 01:47:24PM -0400, Mohammed Naser wrote: > >>> >>> Hi folks, > >>> >>> > >>> >>> I've attempted to enable mod_wsgi support in our dev environment > with > >>> >>> Puppet however it results in a traceback. I figured it was an > >>> >>> environment thing so I looked into moving the Puppet CI to test > using > >>> >>> mod_wsgi and it resulted in the same error. > >>> >>> > >>> >>> > >>> >>> http://logs.openstack.org/82/500182/3/check/gate-puppet-open > stack-integration-4-scenario004-tempest-ubuntu-xenial/ > 791523c/logs/apache/neutron_wsgi_error.txt.gz > >>> >>> > >>> >>> Would anyone from the Neutron team be able to give input on this? > >>> >>> We'd love to add gating for Neutron deployed by mod_wsgi which can > >>> >>> help find similar issues. > >>> >>> > >>> >> > >>> >> Neutron never got their wsgi support working in Devstack either. The > >>> >> patch > >>> >> adding that: https://review.openstack.org/#/c/439191/ never passed > the > >>> >> gate and > >>> >> seems to have lost the attention of the author. The wsgi support in > >>> >> neutron > >>> >> probably doesn't work yet, and is definitely untested. IIRC, the > issue > >>> >> they were > >>> >> hitting was loading the config files. [1] I don't think I saw any > >>> >> progress on it > >>> >> after that though. > >>> >> > >>> >> The TC goal doc [2] probably should say something about it never > >>> >> landing and > >>> >> missing pike. > >>> >> > >>> > > >>> > That would make sense. The release notes also state that it does > >>> > offer the ability to run inside mod_wsgi which can be misleading to > >>> > deployers (that was the main reason I thought we can start testing > >>> > using it): > >>> > > >>> Sigh, hit send too early. Here is the link: > >>> > >>> > >>> http://git.openstack.org/cgit/openstack/neutron/commit/?id=9 > 16bc96ee214078496b4b38e1c93f36f906ce840 > >>> > > >>> >> > >>> >> -Matt Treinish > >>> >> > >>> >> > >>> >> [1] > >>> >> http://lists.openstack.org/pipermail/openstack-dev/2017-June > /117830.html > >>> >> [2] > >>> >> https://governance.openstack.org/tc/goals/pike/deploy-api-in > -wsgi.html#neutron > >>> >> > >>> >> > >>> >> ____________________________________________________________ > ______________ > >>> >> 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 > >>> >> > >>> > >>> ____________________________________________________________ > ______________ > >>> OpenStack Development Mailing List (not for usage questions) > >>> Unsubscribe: openstack-dev-requ...@lists.op > enstack.org?subject:unsubscribe > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > >> ____________________________________________________________ > ______________ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: openstack-dev-requ...@lists.op > enstack.org?subject:unsubscribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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
