Open Stack

On Mon, Sep 4, 2017 at 10:40 AM, Mohammed Naser <mnaser at vexxhost.com> wrote:
> On Mon, Sep 4, 2017 at 9:01 AM, Kevin Benton <kevin at 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-openstack-integration-4-scenario004-tempest-ubuntu-xenial/791523c/logs/etc/neutron/plugins/
>>
>> On Sun, Sep 3, 2017 at 12:03 PM, Mohammed Naser <mnaser at vexxhost.com> wrote:
>>>
>>> On Sun, Sep 3, 2017 at 3:03 PM, Mohammed Naser <mnaser at vexxhost.com>
>>> wrote:
>>> > On Sun, Sep 3, 2017 at 2:20 PM, Matthew Treinish <mtreinish at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>