I'm not sure I understand the behavior you are seeing. When your mechanism driver gets initialized and kicks off processing, all of that should be happening in the parent PID. I don't know why your child processes start executing code that wasn't invoked. Can you provide a pointer to the code or give a sample that reproduces the issue?
I modified the linuxbridge mech driver to try to reproduce it: http://paste.openstack.org/show/216859/ In the output, I never received any of the init code output I added more than once, including the function spawned using eventlet. The only time I ever saw anything executed by a child process was actual API requests (e.g. the create_port method). On Thu, May 7, 2015 at 6:08 AM, Neil Jerram <neil.jer...@metaswitch.com> wrote: > Is there a design for how ML2 mechanism drivers are supposed to cope with > the Neutron server forking? > > What I'm currently seeing, with api_workers = 2, is: > > - my mechanism driver gets instantiated and initialized, and immediately > kicks off some processing that involves communicating over the network > > - the Neutron server process then forks into multiple copies > > - multiple copies of my driver's network processing then continue, and > interfere badly with each other :-) > > I think what I should do is: > > - wait until any forking has happened > > - then decide (somehow) which mechanism driver is going to kick off that > processing, and do that. > > But how can a mechanism driver know when the Neutron server forking has > happened? > > Thanks, > Neil > > __________________________________________________________________________ > 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 > -- Kevin Benton
__________________________________________________________________________ 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
