<p dir="ltr">Why pymysql over mysql-python?</p>
<p dir="ltr">Endre Karlson</p>
<div class="gmail_quote">21. Aug. 2014 09:05 skrev "Angus Lees" <<a href="mailto:gus@inodes.org">gus@inodes.org</a>> følgende:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, 20 Aug 2014 05:03:51 PM Clark Boylan wrote:<br>
> On Mon, Aug 18, 2014, at 01:59 AM, Ihar Hrachyshka wrote:<br>
> > -----BEGIN PGP SIGNED MESSAGE-----<br>
> > Hash: SHA512<br>
> ><br>
> > On 17/08/14 02:09, Angus Lees wrote:<br>
> > > On 16 Aug 2014 06:09, "Doug Hellmann" <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a><br>
> > ><br>
> > > <mailto:<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>>> wrote:<br>
> > >> On Aug 15, 2014, at 9:29 AM, Ihar Hrachyshka<br>
> > >> <<a href="mailto:ihrachys@redhat.com">ihrachys@redhat.com</a><br>
> > ><br>
> > > <mailto:<a href="mailto:ihrachys@redhat.com">ihrachys@redhat.com</a>>> wrote:<br>
> > >>> Signed PGP part Some updates on the matter:<br>
> > >>><br>
> > >>> - oslo-spec was approved with narrowed scope which is now<br>
> > >>> 'enabled mysqlconnector as an alternative in gate' instead of<br>
> > >>> 'switch the default db driver to mysqlconnector'. We'll revisit<br>
> > >>> the switch part the next cycle once we have the new driver<br>
> > >>> running in gate and real benchmarking is heavy-lifted.<br>
> > >>><br>
> > >>> - there are several patches that are needed to make devstack<br>
> > >>> and tempest passing deployment and testing. Those are collected<br>
> > >>> under the hood of: <a href="https://review.openstack.org/#/c/114207/" target="_blank">https://review.openstack.org/#/c/114207/</a> Not<br>
> > >>> much of them.<br>
> > >>><br>
> > >>> - we'll need a new oslo.db release to bump versions (this is<br>
> > >>> needed to set raise_on_warnings=False for the new driver, which<br>
> > >>> was incorrectly set to True in sqlalchemy till very recently).<br>
> > >>> This is expected to be released this month (as per Roman<br>
> > >>> Podoliaka).<br>
> > >><br>
> > >> This release is currently blocked on landing some changes in<br>
> > >> projects<br>
> > ><br>
> > > using the library so they don?t break when the new version starts<br>
> > > using different exception classes. We?re tracking that work in<br>
> > > <a href="https://etherpad.openstack.org/p/sqla_exceptions_caught" target="_blank">https://etherpad.openstack.org/p/sqla_exceptions_caught</a><br>
> > ><br>
> > >> It looks like we?re down to 2 patches, one for cinder<br>
> > ><br>
> > > (<a href="https://review.openstack.org/#/c/111760/" target="_blank">https://review.openstack.org/#/c/111760/</a>) and one for glance<br>
> > > (<a href="https://review.openstack.org/#/c/109655" target="_blank">https://review.openstack.org/#/c/109655</a>). Roman, can you verify<br>
> > > that those are the only two projects that need changes for the<br>
> > > exception issue?<br>
> > ><br>
> > >>> - once the corresponding patch for sqlalchemy-migrate is<br>
> > >>> merged, we'll also need a new version released for this.<br>
> > ><br>
> > > So we're going for a new version of sqlalchemy?  (We have a<br>
> > > separate workaround for raise_on_warnings that doesn't require the<br>
> > > new sqlalchemy release if this brings too many other issues)<br>
> ><br>
> > Wrong. We're going for a new version of *sqlalchemy-migrate*. Which is<br>
> > the code that we inherited from Mike and currently track in stackforge.<br>
> ><br>
> > >>> - on PyPI side, no news for now. The last time I've heard from<br>
> > >>> Geert (the maintainer of MySQL Connector for Python), he was<br>
> > >>> working on this. I suspect there are some legal considerations<br>
> > >>> running inside Oracle. I'll update once I know more about<br>
> > >>> that.<br>
> > >><br>
> > >> If we don?t have the new package on PyPI, how do we plan to<br>
> > >> include it<br>
> > ><br>
> > > in the gate? Are there options to allow an exception, or to make<br>
> > > the mirroring software download it anyway?<br>
> > ><br>
> > > We can test via devstack without waiting for pypi, since devstack<br>
> > > will install via rpms/debs.<br>
> ><br>
> > I expect that it will be settled. I have no indication that the issue<br>
> > is unsolvable, it will just take a bit more time than we're accustomed<br>
> > to. :)<br>
> ><br>
> > At the moment, we install MySQLdb from distro packages for devstack.<br>
> > Same applies to new driver. It will be still great to see the package<br>
> > published on PyPI so that we can track its version requirements<br>
> > instead of relying on distros to package it properly. But I don't see<br>
> > it as a blocker.<br>
> ><br>
> > Also, we will probably be able to run with other drivers supported by<br>
> > SQLAlchemy once all the work is done.<br>
><br>
> So I got bored last night and decided to take a stab at making PyMySQL<br>
> work since I was a proponent of it earlier. Thankfully it did just<br>
> mostly work like I thought it would.<br>
> <a href="https://review.openstack.org/#/c/115495/" target="_blank">https://review.openstack.org/#/c/115495/</a> is the WIP devstack change to<br>
> test this out.<br>
<br>
Thanks!<br>
<br>
> Postgres tests fail because it was applying the pymysql driver to the<br>
> postgres connection string. We can clean this up later in devstack<br>
> and/or devstack-gate depending on how we need to apply this stuff.<br>
> Bashate failed because I had to "monkeypatch" in a fix for a ceilometer<br>
> issue loading sqlalchemy drivers. The tempest neutron full job fails on<br>
> one test occasionally. Not sure yet if that is normal neutron full<br>
> failure mode or if a new thing from PyMySQL. The regular tempest job<br>
> passes just fine.<br>
><br>
> There are also some DB related errors in the logs that will need to be<br>
> cleaned up but overall it just works. So I would like to repropose that<br>
> we stop focusing all of this effort on the hard thing and use the easy<br>
> thing if it meets our needs. We can continue to make alternatives work,<br>
> but that is a different problem that we can solve at a different pace. I<br>
> am not sure how to test the neutron thing that Gus was running into<br>
> though so we should also check that really quickly.<br>
<br>
TL;DR: pymysql passes my test case.<br>
I'm perfectly happy to move towards using mysql+pymysql in gate tests.  (The<br>
various changes I've been submitting are to support _any_ non-default driver).<br>
<br>
If anyone cares, my test case is in <a href="https://review.openstack.org/#/c/104436/" target="_blank">https://review.openstack.org/#/c/104436/</a><br>
Unfortunately it requires a small amount of hacking up the relevant utils.py<br>
functions to test with an arbitrary sqlalchemy connect string.  I had some<br>
clumsy attempts at making that easier, but they were rejected in favour of a<br>
far better solution that still hasn't landed yet :/<br>
<br>
--<br>
 - Gus<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>