On Wed, Oct 23, 2013 at 4:37 PM, Nachi Ueno <nachi at ntti3.com> wrote: > Hi Phil > > 2013/10/21 Day, Phil <philip.day at hp.com>: > > Hi Folks, > > > > > > > > I’m trying to track down a couple of obsecure issues in network port > > creation where it would be really useful if I could disable the async > > network allocation so that everything happens in the context of a single > > eventlet rather than two (and also rule out if there is some obscure > > eventlet threading issue in here). I thought it was configurable – but > I > > don’t see anything obvious in the code to go back to the old (slower) > > approach of doing network allocation in-lien in the main create thread ? > > > I agree, I don't see anywhere to make it configurable either > > May I ask the meaning of " async network allocation" ? > > I believe he's referring to: https://github.com/openstack/nova/blob/master/nova/network/model.py#L335 https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L1211 > > > > One of the issues I’m trying to track is Neutron occasionally creating > more > > than one port – I suspect a retry mechanism in the httplib2 is sending > the > > port create request multiple times if Neutron is slow to reply, > resulting > > in Neutron processing it multiple times. Looks like only the Neutron > client > > has chosen to use httplib2 rather that httplib – anyone got any insight > here > > ? > > This is a quite interest findings. so If we use httplib, this won't happen? > > > > > > > Sometimes of course the Neutron timeout results in the create request > being > > re-scheduled onto another node (which can it turn generate its own set of > > port create requests). Its the thread behavior around how the timeout > > exception is handled that I’m slightly nervous of (some of the retries > seem > > to occur after the original network thread should have terminated). > > > > I agree. The kind of unintentional retry causes issues. > > > > > Thanks > > > > Phil > > > > Best > Nachi > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131023/c19ef7ad/attachment.html>