Open Stack

On Mon, Sep 4, 2017 at 11:07 AM, Kevin Benton <kevin at benton.pub> wrote:
> #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.

I think you might have missed my message earlier by a few seconds,
looks like it's not really 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).
>

I believe that would be the best option, I did a bit of research and I
have the following in regards to distros:

- RDO uses /etc/neutron/plugin.ini:
https://github.com/rdo-packages/neutron-distgit/blob/rpm-master/neutron-server.service#L8
- Ubuntu configures `/etc/neutron/plugins/ml2/ml2_conf.ini` in
`/etc/neutron/default` which is why in Puppet we override that to keep
things consistent.
(https://launchpad.net/ubuntu/+source/neutron/2:11.0.0-0ubuntu1 --
downloaded control files from there).

I have mixed feelings about this.  I think we should add
`/etc/neutron/plugin.ini` and advice Ubuntu packaging to change their
default (with a plugin.ini as a symlink).  If we introduce both
`ml2_conf.ini` and `plugin.ini`, we risk creating problems if someone
is not using the `ml2` plugin.  Alternatively, you could load
`plugin.ini` and fallback to `/etc/neutron/plugins/ml2/ml2_conf.ini`
if there is nothing?  It's a hard call but it should probably be
decided by the Neutron team in coordination with the distribution
packagers.

>
> On Mon, Sep 4, 2017 at 7: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'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
>> >
>>
>> __________________________________________________________________________
>> 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
>