Open Stack

On Wed, Aug 31, 2016 at 12:09 PM, Doug Hellmann <doug at doughellmann.com> wrote:
> Excerpts from Ihar Hrachyshka's message of 2016-08-31 16:48:09 +0200:
>> Mike Bayer <mbayer at redhat.com> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: https://twitter.com/dims