[openstack-dev] [neutron] Mechanism drivers and Neutron server forking?

Kevin Benton blak111 at gmail.com
Fri May 8 07:43:21 UTC 2015


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.Jerram at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150508/f84c34d5/attachment.html>


More information about the OpenStack-dev mailing list