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
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
>
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
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
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
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
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
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
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
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
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
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
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
13 matches
Mail list logo