On 06/21/2018 04:48 PM, Nate Johnston wrote: > I will continue to debug the issue tomorrow. I see no lonkage at this > point with any of the previously listed constraints on this scenario. > So I am going to copy Brian Haley for his L3 expertise, as well as the 3 > FWAaaS cores to see if this directs their thoughts in any particular > direction. I hope to continue the investigation tomorrow. > > Thanks, > > Nate Johnston > njohnston
Hi there, As per IRC discussion, let me explain to everyone the difference between what I've done in Debian, and what's in the other distributions. First, I would like to highlight the fact that this isn't at all Debian specific. 1/ Why doing: neutron-server -> neutron-api + neutron-rpc-server On other distros, we use Python 2, therefore neutron-server can be in use, and that works with or without SSL. In Debian, since we've switched to Python 3, an Eventlet based API daemon cannot work with SSL, due to a bug in Eventlet itself. That bug has been known since 2015, with no fix coming. What happens is that when a client connects to the API server, due to Eventlet's monkey patching, non-blocking stuff produce an SSL handshake. As a consequence, the only way to run Neutron with Python 3 and SSL, is to avoid neutron-server, and use either uwsgi, or mod_uwsgi. In Debian, most daemons are using uwsgi when possible. In such mode, the WSGI application is /usr/bin/neutron-api. But this WSGI application, as it's not a daemon (but an API only, served by a web server), cannot have a a thread to listen to the RPC bus. So instead, there's neutron-rpc-server to do that job. 2/ Bugs already fixed but not merged in neutron for this mode An Nguyen Phong (annp on IRC) has fixed stuff in neutron for that mode of operation described above, but it's not yet merged: https://review.openstack.org/#/c/555608/ Without this patch, the l3 agent doesn't know about ml2 extensions, it's impossible to pass startup --config-file= parameters correctly, and the openvswitch agent never applies security-group firewall rules. Please consider reviewing this patch and merging it. 3/ How to reproduce the Debian environment You can always simply install stuff by hand with packages, but that's boringly long to do. The easiest way is to pop a fresh Stretch, and have puppet to run in it to install everything for you. Here's the steps: a) Boot-up a stretch machine with access to the net. b) git clone https://github.com/openstack/puppet-openstack-integration c) cd puppet-openstack-integration d) git review -d 577281 This will re-enable FWaaS for the l3 agent. Hopefully, we'll get to the point where this patch can be applied and FWaaS re-enabled. e) edit all-in-one.sh line 69: --- a/all-in-one.sh +++ b/all-in-one.sh @@ -66,7 +66,7 @@ export GEM_HOME=`pwd`/.bundled_gems gem install bundler --no-rdoc --no-ri --verbose set -e -./run_tests.sh +SCENARIO=scenario001 ./run_tests.sh RESULT=$? set +e if [ $RESULT -ne 0 ]; then f) git commit -a -m "test scenario001" g) ./all-in-one.sh Note that you may as well test scenario 2 & 4 which are also using OVS, or scenario 3 that is using linuxbridge. After approx one hour, you'll get a full Debian all-in-one installation using packages. If you're not used to it, all the code is in /usr/lib/python3/dist-packages. You may edit code there for your tests. If you need to re-run a single test, you can do this: cp /tmp/openstack/tempest/etc/tempest.conf /etc/tempest cd /var/lib/tempest tempest_debian_shell_wrapper \ tempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basic_ops Just have a look at /usr/bin/tempest_debian_shell_wrapper, it's a tiny small shell script to run tests easily. Also, feel free to attempt switching to firewall_v2 in configuration files in /etc/neutron, and then restart the daemons. By default, it's still v1, but if it works with v2, we'll happily apply patches in puppet-openstack for that (which will apply for all distros). If you need me, just type "zigo" on IRC (I'm in most channels, including #openstack-neutron and #openstack-fwaas), and I'll reply if it's office hours in Geneva/France, or late in my evening. I hope the above helps, Cheers, Thomas Goirand (zigo) __________________________________________________________________________ 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