Re: [openstack-dev] Performance Regression in Neutron/Havana compared to Quantum/Grizzly

2013-12-10 Thread Peter Feiner
On Tue, Dec 10, 2013 at 7:48 AM, Nathani, Sreedhar (APS) wrote: > My setup has 17 L2 agents (16 compute nodes, one Network node). Setting the > minimize_polling helped to reduce the CPU > utilization by the L2 agents but it did not help in instances getting the IP > during first boot. > > With t

Re: [openstack-dev] Performance Regression in Neutron/Havana compared to Quantum/Grizzly

2013-12-05 Thread Peter Feiner
On Thu, Dec 5, 2013 at 8:23 AM, Nathani, Sreedhar (APS) wrote: > Hello Marun, > > > > Please find the details about my setup and tests which i have done so far > > > > Setup > > - One Physical Box with 16c, 256G memory. 2 VMs created on this Box - One > for Controller and One for Network Node >

Re: [openstack-dev] [nova] Do we have some guidelines for mock, stub, mox when writing unit test?

2013-12-04 Thread Peter Feiner
On Wed, Dec 4, 2013 at 11:16 AM, Nikola Đipanov wrote: > 1) Figure out what is the deal with mox3 and decide if owning it will > really be less trouble than porting nova. To be hones - I was unable to > even find the code repo for it, only [3]. If anyone has more info - > please weigh in. We'll al

Re: [openstack-dev] [nova] Do we have some guidelines for mock, stub, mox when writing unit test?

2013-11-19 Thread Peter Feiner
On Tue, Nov 19, 2013 at 11:19 AM, Chuck Short wrote: > Hi > > > On Tue, Nov 19, 2013 at 10:43 AM, Peter Feiner wrote: >> >> A substantive reason for switching from mox to mock is the derelict >> state of mox releases. There hasn't been a release of mox in th

Re: [openstack-dev] [nova] Do we have some guidelines for mock, stub, mox when writing unit test?

2013-11-19 Thread Peter Feiner
A substantive reason for switching from mox to mock is the derelict state of mox releases. There hasn't been a release of mox in three years: the latest, mox-0.5.3, was released in 2010 [1, 2]. Moreover, in the past 3 years, substantial bugs have been fixed in upstream mox. For example, with the ye

Re: [openstack-dev] Keystone Concurrency & Races in SQL Assignment Backend

2013-10-31 Thread Peter Feiner
so that tempest > is going to pass consistently. > > - Brant > > On Wed, Oct 30, 2013 at 5:08 PM, Peter Feiner wrote: >> >> Hi Brant, >> >> In addition to the race you've fixed in >> https://review.openstack.org/#/c/50767/, it looks like there are qu

[openstack-dev] Keystone Concurrency & Races in SQL Assignment Backend

2013-10-30 Thread Peter Feiner
Hi Brant, In addition to the race you've fixed in https://review.openstack.org/#/c/50767/, it looks like there are quite a few more races in the SQL backend of keystone.assignment. I filed a bug to this effect: https://bugs.launchpad.net/keystone/+bug/1246489. The general problem is that transacti

[openstack-dev] [Nova] FFE Request: condutor-workers

2013-09-06 Thread Peter Feiner
Russell & Thierry, I think conductor-workers [1] should be an exception to the feature freeze for H3. The risk is very low since the default value of this configuration option doesn't change nova's behavior at all. Moreover, the patch [2] is small and uses common OpenStack code. The reward is high

Re: [openstack-dev] Article on Improving Openstack's Parallel Performance

2013-07-30 Thread Peter Feiner
On Mon, Jul 29, 2013 at 7:06 PM, Aaron Rosen wrote: > Hi Peter, > > Great article. Any interest in pushing your N-work quantum-server patch > upstream? Thanks Aaron! I'm certainly interested in pushing the patch upstream :-) When I submit a review, we'll see if the community reciprocates. As on

[openstack-dev] Article on Improving Openstack's Parallel Performance

2013-07-22 Thread Peter Feiner
Hello, I've written an article about my ongoing work on improving OpenStack's parallel performance: http://blog.gridcentric.com/bid/318277/Boosting-OpenStack-s-Parallel-Performance The article discusses host configuration changes and patches (upstream and in progress) that give a 74% speedup in

Re: [openstack-dev] Moving task flow to conductor - concern about scale

2013-07-19 Thread Peter Feiner
On Fri, Jul 19, 2013 at 4:36 PM, Joshua Harlow wrote: > This seems to me to be a good example where a library "problem" is leaking > into the openstack architecture right? That is IMHO a bad path to go down. > > I like to think of a world where this isn't a problem and design the correct > solut

Re: [openstack-dev] Moving task flow to conductor - concern about scale

2013-07-19 Thread Peter Feiner
On Fri, Jul 19, 2013 at 10:15 AM, Dan Smith wrote: > > > So rather than asking "what doesn't work / might not work in the > > future" I think the question should be "aside from them both being > > things that could be described as a conductor - what's the > > architectural reason for wanting to ha

Re: [openstack-dev] Moving task flow to conductor - concern about scale

2013-07-19 Thread Peter Feiner
On Fri, Jul 19, 2013 at 11:06 AM, Dan Smith wrote: > FWIW, I don't think anyone is suggesting a single conductor, and > especially not a single database proxy. This is a critical detail that I missed. Re-reading Phil's original email, I see you're debating the ratio of nova-conductor DB proxies t