On 12/17/2015 04:00 PM, Thomas Goirand wrote: > On 12/16/2015 06:04 PM, Mike Bayer wrote: >> >> >> On 12/16/2015 11:53 AM, Sean Dague wrote: >>> On 12/16/2015 11:37 AM, Sean Dague wrote: >>>> On 12/16/2015 11:22 AM, Mike Bayer wrote: >>>>> >>>>> >>>>> On 12/16/2015 09:10 AM, Sylvain Bauza wrote: >>>>>> >>>>>> >>>>>> Le 16/12/2015 14:59, Sean Dague a écrit : >>>>>>> oslo.db test_migrations is using methods for alembic, which changed in >>>>>>> the 0.8.4 release. This ends up causing a unit test failure (at least in >>>>>>> the Nova case) that looks like this - >>>>>>> http://logs.openstack.org/44/258444/1/check/gate-nova-python27/2ed0401/console.html#_2015-12-16_12_20_17_404 >>>>>>> >>>>>>> >>>>>>> There is an oslo.db patch out there >>>>>>> https://review.openstack.org/#/c/258478 to fix it, but #openstack-oslo >>>>>>> has been pretty quiet this morning, so no idea how fast this can get out >>>>>>> into a release. >>>>>>> >>>>>>> -Sean >>>>>>> >>>>>> >>>>>> So, it seems that the issue came when >>>>>> https://bitbucket.org/zzzeek/alembic/issues/341 was merged. >>>>>> Fortunatelt, Mike seems to have a patch in place for Nova in order to >>>>>> fix this https://review.openstack.org/#/c/253859/ >>>>>> >>>>>> I'd suggest an intensive review pass on that one to make sure it's OK. >>>>> >>>>> do you folks have a best practice suggestion on this? My patch kind of >>>>> stayed twisting in the wind for a week even though those who read it >>>>> would have seen "hey, this is going to break on Alembic's next minor >>>>> release!" I pinged the important people and all on it, but it still >>>>> got no attention. >>>> >>>> Which people were those? I guess none of us this morning knew this was >>>> going to be an issue and were surprised that 12 hours worth of patches >>>> had all failed. >>>> >>>> -Sean >>> >>> Best practice is send an email to the openstack-dev list: >>> >>> Subject: [all] the following test jobs will be broken by Alembic 0.8.4 >>> release >>> >>> The Alembic 0.8.4 release is scheduled on 12/15. When it comes out it >>> will break Nova unit tests on all branches. >>> >>> The following patch will fix master - ..... >>> >>> You all will need to backport it as well to all branches. >>> >>> >>> Instead of just breaking the world, and burning 10s to 100 engineer >>> hours in redo tests and investigating and addressing the break after the >>> fact. >> >> I was hoping to get a thanks for even *testing* unreleased versions of >> my entirely non-Openstack, upstream projects against Openstack itself. >> If I did *less* effort here, and just didn't bother the way 100% of all >> other non-Openstack projects do, then I'd not have been scolded by you. > > IMHO, it shouldn't be *tested*, but *gated*. Meaning that such a > disruptive patch should be accepted only when there's a fix in all of > OpenStack (if that is possible, of course, as I don't really know the > details, just this thread...). > > Or do you still consider SQLA / Alembic as just a 3rd party lib for > OpenStack? Wouldn't it be nice to have it maintained directly in > OpenStack infra? Your thoughts?
Alembic / SQLAlchemy are completely outside of Openstack and are intrinsic to thousands of non-Openstack environments and userbases. I wonder why don't we ask the same question of other Openstack dependencies, like numpy, lxml, boto, requests, rabbitMQ, and everything else. As far as it being *gated*, that is already the plan within Openstack itself via the upper-constraints system discussed in this thread, which I mistakenly thought was already in use across the board. That is, new release of library X hits pypi, some series of CI only involved with testing new releases of libs above that of upper-constraints runs tests on it to see if it breaks current openstack applications, and if so, the constraints file stays unchanged and the bulk of gate jobs remain unaffected. > > Cheers, > > Thomas Goirand (zigo) > > > __________________________________________________________________________ > 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 > __________________________________________________________________________ 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
