Re: [openstack-dev] [oslo] pymysql change in error formatting has broken exception handing in oslo.db
> upstream issue: > > https://github.com/PyMySQL/PyMySQL/issues/507 A fix for this was merged in pymysql 0.7.8. --diana __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] pymysql change in error formatting has broken exception handing in oslo.db
+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). https://review.openstack.org/#/c/364063/ Enjoy! -Josh __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] pymysql change in error formatting has broken exception handing in oslo.db
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 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] pymysql change in error formatting has broken exception handing in oslo.db
On Wed, Aug 31, 2016 at 12:09 PM, Doug Hellmann wrote: > Excerpts from Ihar Hrachyshka's message of 2016-08-31 16:48:09 +0200: >> Mike Bayer 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-requ...@lists.openstack.org?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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] pymysql change in error formatting has broken exception handing in oslo.db
Excerpts from Ihar Hrachyshka's message of 2016-08-31 16:48:09 +0200: > Mike Bayer 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 > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] pymysql change in error formatting has broken exception handing in oslo.db
On Wed, Aug 31 2016, Ihar Hrachyshka wrote: > 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. This is also my plan and proposal. At least the Gnocchi gate is broken now until oslo.db is fixed, so we're really eager to see things moving… :) -- Julien Danjou # Free Software hacker # https://julien.danjou.info signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] pymysql change in error formatting has broken exception handing in oslo.db
On 08/31/2016 10:48 AM, Ihar Hrachyshka wrote: 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. upstream issue: https://github.com/PyMySQL/PyMySQL/issues/507 PyMySQL tends to be very responsive to issues (plus I think I'm a committer anyway, even I could commit a fix I suppose) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] pymysql change in error formatting has broken exception handing in oslo.db
Mike Bayer 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. Ihar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
