[openstack-dev] [Neutron] The three API server multi-worker process patches.

Brian Cline bcline at softlayer.com
Wed Sep 4 21:34:41 UTC 2013


Was any consensus on this ever reached? It appears both reviews are still open. I'm partial to review 37131 as it attacks the problem a more concisely, and, as mentioned, combined the efforts of the two more effective patches. I would echo Carl's sentiments that it's an easy review minus the few minor behaviors discussed on the review thread today.

We feel very strongly about these making it into Havana -- being confined to a single neutron-server instance per cluster or region is a huge bottleneck--essentially the only controller process with massive CPU churn in environments with constant instance churn, or sudden large batches of new instance requests.

In Grizzly, this behavior caused addresses not to be issued to some instances during boot, due to quantum-server thinking the DHCP agents timed out and were no longer available, when in reality they were just backlogged (waiting on quantum-server, it seemed).

Is it realistically looking like this patch will be cut for h3?

--
Brian Cline
Software Engineer III, Product Innovation

SoftLayer, an IBM Company
4849 Alpha Rd, Dallas, TX 75244
214.782.7876 direct  |  bcline at softlayer.com
 

-----Original Message-----
From: Baldwin, Carl (HPCS Neutron) [mailto:carl.baldwin at hp.com] 
Sent: Wednesday, August 28, 2013 3:04 PM
To: Mark McClain
Cc: OpenStack Development Mailing List
Subject: [openstack-dev] [Neutron] The three API server multi-worker process patches.

All,

We've known for a while now that some duplication of work happened with
respect to adding multiple worker processes to the neutron-server.  There
were a few mistakes made which led to three patches being done
independently of each other.

Can we settle on one and accept it?

I have changed my patch at the suggestion of one of the other 2 authors,
Peter Feiner, in attempt to find common ground.  It now uses openstack
common code and therefore it is more concise than any of the original
three and should be pretty easy to review.  I'll admit to some bias toward
my own implementation but most importantly, I would like for one of these
implementations to land and start seeing broad usage in the community
earlier than later.

Carl Baldwin

PS Here are the two remaining patches.  The third has been abandoned.

https://review.openstack.org/#/c/37131/
https://review.openstack.org/#/c/36487/


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list