Open Stack

<snip>

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

I'll get a release review up once 
https://review.openstack.org/#/c/363828/ merges (seems to be on its way 
to merging).

-Josh