On Wed, Aug 31, 2016 at 12:09 PM, Doug Hellmann <[email protected]> wrote: > Excerpts from Ihar Hrachyshka's message of 2016-08-31 16:48:09 +0200: >> Mike Bayer <[email protected]> wrote: >> >> > We need to decide how to handle this: >> > >> > https://review.openstack.org/#/c/362991/ >> > >> > >> > Basically, PyMySQL normally raises an error message like this: >> > >> > (pymysql.err.IntegrityError) (1452, u'Cannot add or update a child row: a >> > foreign key constraint fails (`vaceciqnzs`.`resource_entity`, CONSTRAINT >> > `foo_fkey` FOREIGN KEY (`foo_id`) REFERENCES `resource_foo` (`id`))') >> > >> > for some reason, PyMySQL 0.7.7 is now raising it like this: >> > >> > (pymysql.err.IntegrityError) (1452, u'23000Cannot add or update a child >> > row: a foreign key constraint fails (`vaceciqnzs`.`resource_entity`, >> > CONSTRAINT `foo_fkey` FOREIGN KEY (`foo_id`) REFERENCES `resource_foo` >> > (`id`))') >> > >> > this impacts oslo.db's "exception re-handling" functionality which tries >> > to classify this exception as a DBNonExistentConstraint exception. It >> > also breaks oslo.db's test suite locally, but in a downstream project >> > would only impact its ability to intercept this exception appropriately. >> > >> > now that "23000" there looks like a bug. The above gerrit proposes to >> > work around it. However, if we didn't push out the above gerrit, we'd >> > instead have to change requirements: >> > >> > https://review.openstack.org/#/q/I33d5ef8f35747d3b6d3bc0bd4972ce3b7fd60371,n,z >> > >> > It seems like at least one or the other would be needed for Newton. >> >> Unless we fix the bug in next pymysql, it’s not either/or but both will be >> needed, and also minimal oslo.db version bump. >> >> I suggest we: >> - block 0.7.7 to unblock upper-constraints updates; >> - land oslo.db fix to cope with pymysql 0.7.7+, in master as well as all >> stable branches; >> - release new oslo.db releases for L-N; >> - at least for N, bump minimal version of the library in >> global-requirements.txt; >> - sync the bump to all consuming projects; >> - later, maybe unblock 0.7.7. >> >> In the meantime, interested parties may work with pymysql folks to get the >> issue fixed. It may take a while, so I would not make this step part of our >> short term plan. >> >> Now, I understand that this does not really sound ideal, but I assume we >> are not in requirements freeze yet (the deadline for that is tomorrow), and >> this plan will solve the issue for users of all versions of pymysql. > > Even if we were frozen, this seems like the sort of thing we'd want to > deal with through a patch release. > > I've already create the stable/newton branch for oslo.db, so we'll need > to backport the fix to have a 4.13.1 release.
+1 to 4.13.1 Thanks, Dims > > Doug > >> >> Ihar >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
