[Openstack-operators] [nova] FYI, local conductor mode is deprecated, pending removal in N

Andrew Laski andrew at lascii.com
Thu Nov 12 21:25:28 UTC 2015


On 11/12/15 at 10:53am, Clint Byrum wrote:
>Excerpts from Joshua Harlow's message of 2015-11-12 10:35:21 -0800:
>> Mike Dorman wrote:
>> > We do have a backlog story to investigate this more deeply, we just have not had the time to do it yet.  For us, it’s been easier/faster to add more hardware to conductor to get over the hump temporarily.
>> >
>> > We kind of have that work earmarked for after the Liberty upgrade, in hopes that maybe it’ll be fixed there.
>> >
>> > If anybody else has done even some trivial troubleshooting already, it’d be great to get that info as a starting point.  I.e. which specific calls to conductor are causing the load, etc.
>> >
>> > Mike
>> >
>>
>> +1 I think we in the #openstack-performance channel really need to
>> investigate this, because it really worries me personally from hearing
>> many many rumors about how the remote conductor falls over. Please join
>> there and we can try to work through a plan to figure out what to do
>> about this situation. It would be great if the nova people also joined
>> there (because in the end, likely something in nova will need to be
>> fixed/changed/something else to resolve what appears to be a problem for
>> many operators).
>>
>
>Falling over is definitely a bad sign. ;)
>
>The concept of pushing messages over a bus instead of just making local
>calls shouldn't result in much extra load. Perhaps we just have too many
>layers of unoptimized encapsulation. I have to wonder if something like
>protobuf would help.

Falling over is also a very broad description and doesn't let us know 
what the actual issue is.

 From my experience the performance concern with conductor has been in 
not understanding the ratio of conductor nodes to computes that are 
necessary for our usage.  Conductor doesn't add much extra load, but it 
concentrates it on a smaller number of services.  If we ran one 
conductor per compute I suspect we would have no performance issues, but 
that's a lot of capacity to use for this.

I am curious what conductor/compute ratios that others are trying to 
achieve, given equal hardware types for each, and what are the barriers 
to this happening?

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



More information about the OpenStack-operators mailing list