<div dir="ltr">Did you look into setting config files in an env var? That seemed like the best bet given that #2 is out.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 4, 2017 at 8:19 AM, Mohammed Naser <span dir="ltr"><<a href="mailto:mnaser@vexxhost.com" target="_blank">mnaser@vexxhost.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Sep 4, 2017 at 11:07 AM, Kevin Benton <kevin@benton.pub> wrote:<br>
> #2 would be preferable as well just because we have so many guides/distros<br>
> mentioning the different file locations. I'm not familiar with mod_wsgi<br>
> enough to know if it's possible.<br>
<br>
</span>I think you might have missed my message earlier by a few seconds,<br>
looks like it's not really possible :(<br>
<span class=""><br>
> Another 3rd option may be to edit the oslo config constructor call when<br>
> using that entry point to add some well-known paths for additional config<br>
> files rather than only parsing 'sys.argv[1]'. For example, we could always<br>
> try to add /etc/neutron/plugin.ini to the list which we can document that<br>
> distros/deployment tools should always create or have a symbolic link to a<br>
> plugin-specific config (e.g. ml2_conf.ini).<br>
><br>
<br>
</span>I believe that would be the best option, I did a bit of research and I<br>
have the following in regards to distros:<br>
<br>
- RDO uses /etc/neutron/plugin.ini:<br>
<a href="https://github.com/rdo-packages/neutron-distgit/blob/rpm-master/neutron-server.service#L8" rel="noreferrer" target="_blank">https://github.com/rdo-<wbr>packages/neutron-distgit/blob/<wbr>rpm-master/neutron-server.<wbr>service#L8</a><br>
- Ubuntu configures `/etc/neutron/plugins/ml2/ml2_<wbr>conf.ini` in<br>
`/etc/neutron/default` which is why in Puppet we override that to keep<br>
things consistent.<br>
(<a href="https://launchpad.net/ubuntu/+source/neutron/2:11.0.0-0ubuntu1" rel="noreferrer" target="_blank">https://launchpad.net/ubuntu/<wbr>+source/neutron/2:11.0.0-<wbr>0ubuntu1</a> --<br>
downloaded control files from there).<br>
<br>
I have mixed feelings about this.  I think we should add<br>
`/etc/neutron/plugin.ini` and advice Ubuntu packaging to change their<br>
default (with a plugin.ini as a symlink).  If we introduce both<br>
`ml2_conf.ini` and `plugin.ini`, we risk creating problems if someone<br>
is not using the `ml2` plugin.  Alternatively, you could load<br>
`plugin.ini` and fallback to `/etc/neutron/plugins/ml2/ml2_<wbr>conf.ini`<br>
if there is nothing?  It's a hard call but it should probably be<br>
decided by the Neutron team in coordination with the distribution<br>
packagers.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> On Mon, Sep 4, 2017 at 7:40 AM, Mohammed Naser <<a href="mailto:mnaser@vexxhost.com">mnaser@vexxhost.com</a>> wrote:<br>
>><br>
>> On Mon, Sep 4, 2017 at 9:01 AM, Kevin Benton <kevin@benton.pub> wrote:<br>
>> > Yes, unfortunately I didn't make it back to the patch in time to adjust<br>
>> > devstack to dump all of the configuration into one file (instead of<br>
>> > /etc/neutron/neutron.conf /etc/neutron/plugins/ml2.conf etc). I did test<br>
>> > locally with my dev environment around the time that RPC server patch<br>
>> > went<br>
>> > in, but there may have been a regression since it went in since it's not<br>
>> > tested as Matt pointed out.<br>
>> ><br>
>><br>
>> I've added Puppet into this because I think we would have to take a<br>
>> decision regarding this.  The reason behind the fact that we've always<br>
>> used the two configuration files is because distributions which ship<br>
>> packages actually provide 2 configuration files.<br>
>><br>
>> We use a configuration resource called `neutron_plugin_ml2` which<br>
>> configures things always in `/etc/neutron/plugins/ml2/ml2_<wbr>conf.ini`.<br>
>><br>
>> In the case of Ubuntu/Debian based systems, we update<br>
>> `/etc/default/neutron-server` to point the plugin configuration to<br>
>> `/etc/neutron/plugin.ini` and then we ensure that the file is a<br>
>> symbolic link to `/etc/neutron/plugins/ml2/ml2_<wbr>conf.ini`.<br>
>><br>
>> Now, we have two options in my mind (and I am open for others):<br>
>><br>
>> 1) Configure plugins entirely inside `neutron.conf`<br>
>> This option would solve our issue but introduce another one.  I<br>
>> believe that the order in the start commands would mean that the later<br>
>> configuration files (in this case, the plugin.ini) would have priority<br>
>> over the `neutron.conf` causing an inconsistency, I don't think this<br>
>> is possible.  However, we can work around this by ensuring that the<br>
>> plugin.ini file is empty.  However, we will be introducing service<br>
>> restarts for no reason with that change which can be very confusing<br>
>> for the user as to why configuration is moving.<br>
>><br>
>> 2) Figure out a way to pass 'args' via WSGI?<br>
>> I'm not sure if this is entirely possible at all.  But, could there be<br>
>> a way that we can pass a list of configuration files in the mod_wsgi<br>
>> configuration?  This would make it the most transparent fix without<br>
>> having to adjust all of the configuration files and bend against the<br>
>> set configuration paths of the distro.<br>
>><br>
>> I'd be more than happy to hear any other ideas regarding this<br>
>> solution.  I would love to implement #2 if it is somehow possible<br>
>> (environment variables, maybe?) but #1 would work but be very messy<br>
>> for operators and users.<br>
>><br>
>> ><br>
>> > It appears that puppet is still spreading the config files for the<br>
>> > server<br>
>> > into multiple locations as well[1]. Does it inherit that logic from<br>
>> > devstack? Because that will need to be changed to push all of the<br>
>> > relevant<br>
>> > server config into one conf.<br>
>> ><br>
>> > 1.<br>
>> ><br>
>> > <a href="http://logs.openstack.org/82/500182/3/check/gate-puppet-openstack-integration-4-scenario004-tempest-ubuntu-xenial/791523c/logs/etc/neutron/plugins/" rel="noreferrer" target="_blank">http://logs.openstack.org/82/<wbr>500182/3/check/gate-puppet-<wbr>openstack-integration-4-<wbr>scenario004-tempest-ubuntu-<wbr>xenial/791523c/logs/etc/<wbr>neutron/plugins/</a><br>
>> ><br>
>> > On Sun, Sep 3, 2017 at 12:03 PM, Mohammed Naser <<a href="mailto:mnaser@vexxhost.com">mnaser@vexxhost.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> On Sun, Sep 3, 2017 at 3:03 PM, Mohammed Naser <<a href="mailto:mnaser@vexxhost.com">mnaser@vexxhost.com</a>><br>
>> >> wrote:<br>
>> >> > On Sun, Sep 3, 2017 at 2:20 PM, Matthew Treinish<br>
>> >> > <<a href="mailto:mtreinish@kortar.org">mtreinish@kortar.org</a>><br>
>> >> > wrote:<br>
>> >> >> On Sun, Sep 03, 2017 at 01:47:24PM -0400, Mohammed Naser wrote:<br>
>> >> >>> Hi folks,<br>
>> >> >>><br>
>> >> >>> I've attempted to enable mod_wsgi support in our dev environment<br>
>> >> >>> with<br>
>> >> >>> Puppet however it results in a traceback.  I figured it was an<br>
>> >> >>> environment thing so I looked into moving the Puppet CI to test<br>
>> >> >>> using<br>
>> >> >>> mod_wsgi and it resulted in the same error.<br>
>> >> >>><br>
>> >> >>><br>
>> >> >>><br>
>> >> >>> <a href="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" rel="noreferrer" target="_blank">http://logs.openstack.org/82/<wbr>500182/3/check/gate-puppet-<wbr>openstack-integration-4-<wbr>scenario004-tempest-ubuntu-<wbr>xenial/791523c/logs/apache/<wbr>neutron_wsgi_error.txt.gz</a><br>
>> >> >>><br>
>> >> >>> Would anyone from the Neutron team be able to give input on this?<br>
>> >> >>> We'd love to add gating for Neutron deployed by mod_wsgi which can<br>
>> >> >>> help find similar issues.<br>
>> >> >>><br>
>> >> >><br>
>> >> >> Neutron never got their wsgi support working in Devstack either. The<br>
>> >> >> patch<br>
>> >> >> adding that: <a href="https://review.openstack.org/#/c/439191/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/439191/</a> never passed<br>
>> >> >> the<br>
>> >> >> gate and<br>
>> >> >> seems to have lost the attention of the author. The wsgi support in<br>
>> >> >> neutron<br>
>> >> >> probably doesn't work yet, and is definitely untested. IIRC, the<br>
>> >> >> issue<br>
>> >> >> they were<br>
>> >> >> hitting was loading the config files. [1] I don't think I saw any<br>
>> >> >> progress on it<br>
>> >> >> after that though.<br>
>> >> >><br>
>> >> >> The TC goal doc [2] probably should say something about it never<br>
>> >> >> landing and<br>
>> >> >> missing pike.<br>
>> >> >><br>
>> >> ><br>
>> >> > That would make sense.  The release notes also state that it does<br>
>> >> > offer the ability to run inside mod_wsgi which can be misleading to<br>
>> >> > deployers (that was the main reason I thought we can start testing<br>
>> >> > using it):<br>
>> >> ><br>
>> >> Sigh, hit send too early.  Here is the link:<br>
>> >><br>
>> >><br>
>> >><br>
>> >> <a href="http://git.openstack.org/cgit/openstack/neutron/commit/?id=916bc96ee214078496b4b38e1c93f36f906ce840" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/<wbr>openstack/neutron/commit/?id=<wbr>916bc96ee214078496b4b38e1c93f3<wbr>6f906ce840</a><br>
>> >> ><br>
>> >> >><br>
>> >> >> -Matt Treinish<br>
>> >> >><br>
>> >> >><br>
>> >> >> [1]<br>
>> >> >><br>
>> >> >> <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-June/117830.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2017-<wbr>June/117830.html</a><br>
>> >> >> [2]<br>
>> >> >><br>
>> >> >> <a href="https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html#neutron" rel="noreferrer" target="_blank">https://governance.openstack.<wbr>org/tc/goals/pike/deploy-api-<wbr>in-wsgi.html#neutron</a><br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> ______________________________<wbr>______________________________<wbr>______________<br>
>> >> >> OpenStack Development Mailing List (not for usage questions)<br>
>> >> >> Unsubscribe:<br>
>> >> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>> >> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>> >> >><br>
>> >><br>
>> >><br>
>> >> ______________________________<wbr>______________________________<wbr>______________<br>
>> >> OpenStack Development Mailing List (not for usage questions)<br>
>> >> Unsubscribe:<br>
>> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > ______________________________<wbr>______________________________<wbr>______________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> > <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>> ><br>
>><br>
>> ______________________________<wbr>______________________________<wbr>______________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>