Open Stack

On Mon, Jun 15, 2015 at 6:30 AM, Sean Dague <sean at dague.net> 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.
>
>
Thanks for the excellent summary of where things stand Sean! And thanks to
Armando for jumping on this last week to get things moving so we can
stabilize everything else and sort out the issues Neutron has with pymsql.

Kyle


>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150615/4f0ebac6/attachment.html>