Open Stack

On 6/15/2015 6:30 AM, Sean Dague wrote:
> On 06/11/2015 06:29 AM, Sean Dague wrote:
>> On 06/09/2015 06:42 PM, Jeremy Stanley wrote:
>>> As discussed in the Liberty Design Summit "Moving apps to Python 3"
>>> cross-project workshop, the way forward in the near future is to
>>> switch to the pure-python PyMySQL library as a default.
>>>
>>>      https://etherpad.openstack.org/p/liberty-cross-project-python3
>>>
>>> To that end, support has already been implemented and tested in
>>> DevStack, and when https://review.openstack.org/184493 merges in a
>>> day or two this will become its default. Any last-minute objections
>>> or concerns?
>>>
>>> Note that similar work is nearing completion is oslo.db with
>>> https://review.openstack.org/184392 and there are also a lot of
>>> similar changes in flight for other repos under the same review
>>> topic (quite a few of which have already merged).
>>
>> Ok, we've had 2 days fair warning, I'm pushing the merge button here.
>> Welcome to the world of pure python mysql.
>
> As a heads up for where we stand. The switch was flipped, but a lot of
> neutron jobs (rally & tempest) went into a pretty high failure rate
> after it was (all the other high volume jobs seemed fine).
>
> We reverted the change here to unwedge things -
> https://review.openstack.org/#/c/191010/
>
> After a long conversation with Henry and Armando we came up with a new
> plan, because we want the driver switch, and we want to figure out why
> it causes a high Neutron failure rate, but we don't want to block
> everything.
>
> https://review.openstack.org/#/c/191121/ - make the default Neutron jobs
> set some safe defaults (which are different than non Neutron job
> defaults), but add a flag to make it possible to expose these issues.
>
> Then add new non-voting check jobs to Neutron queue to expose these
> issues - https://review.openstack.org/#/c/191141/. Hopefully allowing
> interested parties to get to the bottom of these issues around the db
> layer. It's in the check queue instead of the experimental queue to get
> enough volume to figure out the pattern for the failures, because they
> aren't 100%, and they seem to move around a bit.
>
> Once https://review.openstack.org/#/c/191121/ is landed we'll revert
> revert - https://review.openstack.org/#/c/191113/ and get everything
> else back onto pymysql.
>
> 	-Sean
>

It's not only neutron, I saw some pymysql failures in nova the other day 
for 'too many connections' or some such related error.

-- 

Thanks,

Matt Riedemann