#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). On Mon, Sep 4, 2017 at 7: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'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- > openstack-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- > openstack-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= > 916bc96ee214078496b4b38e1c93f36f906ce840 > >> > > >> >> > >> >> -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.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 > > > > __________________________________________________________________________ > 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
