Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>