As a note, in OSP we also include configuration directories and things alike:
https://review.rdoproject.org/r/gitweb?p=openstack/neutron-distgit.git;a=blob;f=neutron-server.service;h=e68024cb9dc06e474b1ac9473bff93c3d892b4d6;hb=48a9d1aa77506d0c60d5bc448b7c5c303083aa68#l8 Config directories make it a bit more future proof, and able to easily integrate with vendor plugins without the need to modify the service file. On Tue, Sep 5, 2017 at 9:27 AM, Miguel Angel Ajo Pelayo <majop...@redhat.com > wrote: > Why do we need to put all the configuration in a single file? > > That would be a big big change to deployers. It'd be great if we can think > of an alternate solution. (not sure how that's being handled for other > services though). > > Best regards, > Miguel Ángel. > > On Mon, Sep 4, 2017 at 3:01 PM, 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. >> >> 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-o >> penstack-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-open >>> stack-integration-4-scenario004-tempest-ubuntu-xenial/791523 >>> c/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=9 >>> 16bc96ee214078496b4b38e1c93f36f906ce840 >>> > >>> >> >>> >> -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.op >>> enstack.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.op >>> enstack.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:unsubscrib >> e >> 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
