Open Stack

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'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
>