[openstack-dev] [oslo] [telemetry] [requirements] [FFE] Oslo.db 4.13.2

Ihar Hrachyshka ihrachys at redhat.com
Thu Sep 8 08:59:59 UTC 2016


I backported the fix to stable/newton:  
https://review.openstack.org/#/c/367221/

Once it’s in, we’ll trigger another oslo.db release.

As for the blocking patch for requirements:  
https://review.openstack.org/#/c/365565/, I disagree that we should block  
oslo.db 4.13.0, because atm pymysql 0.7.7 is blocked in  
global-requirements.txt:

https://github.com/openstack/requirements/blob/4ace2473e4b2eaa283864d74d241c9705f23dd91/global-requirements.txt#L163

and hence there is no known issue with oslo.db 4.13.0 release. I know there  
is a patch that unblocks the pymysql release on review:  
https://review.openstack.org/#/c/364541/ but it’s not merged right now, so  
I don’t see a reason to include block for oslo.db 4.13.0 now. If anything,  
it’s that latter patch that should include it.

The thing is, there is nothing wrong about oslo.db 4.13.0 comparing to any  
previous release: all of them are broken with pymysql 0.7.7. If we are to  
unblock pymysql 0.7.7 now, we should as well block all previous releases of  
oslo.db, meaning bumping the minimal supported version from 4.10.0+ to  
4.13.3+ (when the later is even released; we are still at the stage of  
backport).

Ihar

Matthew Thode <prometheanfire at gentoo.org> wrote:

> On 09/07/2016 07:44 PM, Joshua Harlow wrote:
>> <snip>
>>> Gnocchi is a service. It's not in the pip requirements list for
>>> ceilometer, so releasing a new version of oslo.db and having that
>>> trigger a new release of gnocchi won't also trigger a new release
>>> of ceilometer to update its dependency list.
>>>
>>> The service projects are not yet at their RC1 point, so haven't been
>>> branched. Neither has the requirements list. If blocking the "bad"
>>> version of oslo.db doesn't trigger a cascade of new library releases, we
>>> should do it before we tag RC1 and branch the requirements list so that
>>> we don't have to try to backport the block into newton.
>>
>> So just to aid this along, wanted to check what was the recommended
>> procedure here. https://review.openstack.org/#/c/366362/ is the final
>> fix for this (I hope).
>>
>> I'm guessing (but would like input before doing much here) we need that
>> backported to stable/newton and getting out 4.13.3
>>
>> Does that sound about right to folks, or was the desire to block pymysql
>> (which I believe is fixed by now?) and then just block the bad oslo.db
>> release (4.13.2) and continue with the release train as is.
>>
>> Want to make sure I pick the right path here ;)
>>
>> -Josh
>>
>> __________________________________________________________________________
>> 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
>
> I think the backport/release and mask of the bad oslo.db should be enough.
>
> --
> -- Matthew Thode (prometheanfire)
>
> __________________________________________________________________________
> 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160908/c532e8ac/attachment.pgp>


More information about the OpenStack-dev mailing list