Open Stack

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).

>
>
>
>
> On 11/12/15, 9:36 AM, "Matt Riedemann"<mriedem at linux.vnet.ibm.com>  wrote:
>
>>
>> On 11/12/2015 8:15 AM, Andrew Laski wrote:
>>> On 11/12/15 at 09:31pm, Yaguang Tang wrote:
>>>> There are still performance issue in large deployment to use
>>>> nova-conductor, how do we make this decision to deprecate local mode?
>>>> I see
>>>> the patch is merged only three days after submit.
>>> There is no timeline for removal of local mode at this time for exactly
>>> the reason you mention.  It will be removed no earlier than the N cycle
>>> though.  The deprecation is intended to signal that deployers should
>>> start thinking about how to move to remote conductor and not expect
>>> local mode to be around forever.  And it was always intended to be
>>> temporary while deployments transitioned.
>>>
>>> It would be helpful if you could report the performance issues that you
>>> are seeing so that remote conductor can be improved to accommodate
>>> deployments of all sizes.
>> Yes, also because this came up in the operators list:
>>
>> http://lists.openstack.org/pipermail/openstack-operators/2015-October/008577.html
>>
>> Conductor was called out but I'm not sure if people have dug into the
>> main issues. I had replied to that other thread if we wanted to pick
>> this up there.
>>
>>>> On Thu, Nov 12, 2015 at 10:51 AM, Matt Riedemann
>>>> <mriedem at linux.vnet.ibm.com
>>>>> wrote:
>>>>> Details are in the change:
>>>>>
>>>>> https://review.openstack.org/#/c/242168/
>>>>>
>>>>> --
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Matt Riedemann
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-operators mailing list
>>>>> OpenStack-operators at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>>
>>>>
>>>>
>>>> --
>>>> Yaguang Tang
>>>> Technical Support, Mirantis China
>>>>
>>>> *Phone*: +86 15210946968
>>>> _______________________________________________
>>>> OpenStack-operators mailing list
>>>> OpenStack-operators at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators