Open Stack

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.

Doug

> 
> Ihar
>