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

[Ihar Hrachyshka]

Tony Breeds  wrote:


On Thu, Sep 08, 2016 at 09:21:57AM -0500, Matthew Thode wrote:


Ya that makes sense, the patch can be altered to just block 4.13.1,2
(assuming 4.13.3 really does fix it)


I feel like we've gotten ourselves (well at least I'm confused) about what
we're trying to achieve here.

It seem to be the primary purpose is to get a release of oslo.db out that  
works

for everyone both requirements consumers and non-consumers.

That seems to be done by:
1. Release oslo.db (4.13.3)
https://review.openstack.org/#/c/367482/
2. Bump upper-constraints to point to the new release
Generated once the review above merges
Once it is generated we can abandon: 
https://review.openstack.org/#/c/366298/
4. Update global-requirements to mark some oslo.db versions as bad
I'll update https://review.openstack.org/#/c/365565 RSN


Agreed. Though I already have a patch for that:  
https://review.openstack.org/#/c/365565/



5. Re-Release library packages that get a new the restricted oslo.db
   requirement.

There is also another goal to unblock PyMysql 0.7.7 from  
global-requirements

and upper-constraints.txt

I don't see the need for this.  If distros were shipping 0.7.7 then maybe  
but

even then it's a risky change at this stage.


Agreed, and I expressed the same sentiment in Matthew’s patches before.



https://packages.gentoo.org/packages/dev-python/pymysql
https://build.opensuse.org/package/show/devel:languages:python/python-PyMySQL
https://launchpad.net/ubuntu/+source/python-pymysql
https://apps.fedoraproject.org/packages/python-PyMySQL
http://ftp.redhat.com/redhat/linux/enterprise/7Server/en/RHOS/SRPMS/python-PyMySQL-0.6.7-2.2.el7ost.src.rpm

The only really compelling reason for unblocking 0.7.7 *now* would be  
because
we can't do it after we branch[1] but if we leave it masked it just means  
that

distro packagers will know to skip it.

We should Abandon https://review.openstack.org/#/c/364541/


Agreed, except that I don’t suggest we should abandon it. If there is some  
interest in unblocking it, then just postpone it to when Ocata is open.


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [telemetry] [requirements] [FFE] Oslo.db 4.13.2

[Tony Breeds]

On Thu, Sep 08, 2016 at 09:21:57AM -0500, Matthew Thode wrote:

> Ya that makes sense, the patch can be altered to just block 4.13.1,2
> (assuming 4.13.3 really does fix it)

I feel like we've gotten ourselves (well at least I'm confused) about what
we're trying to achieve here.

It seem to be the primary purpose is to get a release of oslo.db out that works
for everyone both requirements consumers and non-consumers.

That seems to be done by:
1. Release oslo.db (4.13.3)
https://review.openstack.org/#/c/367482/
2. Bump upper-constraints to point to the new release
Generated once the review above merges
Once it is generated we can abandon: 
https://review.openstack.org/#/c/366298/
4. Update global-requirements to mark some oslo.db versions as bad
I'll update https://review.openstack.org/#/c/365565 RSN
5. Re-Release library packages that get a new the restricted oslo.db
   requirement.

There is also another goal to unblock PyMysql 0.7.7 from global-requirements
and upper-constraints.txt

I don't see the need for this.  If distros were shipping 0.7.7 then maybe but
even then it's a risky change at this stage.

https://packages.gentoo.org/packages/dev-python/pymysql
https://build.opensuse.org/package/show/devel:languages:python/python-PyMySQL
https://launchpad.net/ubuntu/+source/python-pymysql
https://apps.fedoraproject.org/packages/python-PyMySQL
http://ftp.redhat.com/redhat/linux/enterprise/7Server/en/RHOS/SRPMS/python-PyMySQL-0.6.7-2.2.el7ost.src.rpm

The only really compelling reason for unblocking 0.7.7 *now* would be because
we can't do it after we branch[1] but if we leave it masked it just means that
distro packagers will know to skip it.

We should Abandon https://review.openstack.org/#/c/364541/

Yours Tony.

[1] As it has an implict bump in the minimum supported version of oslo.db


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] [telemetry] [requirements] [FFE] Oslo.db 4.13.2

[Matthew Thode]

On 09/08/2016 03:59 AM, Ihar Hrachyshka wrote:
> 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
> 

Ya that makes sense, the patch can be altered to just block 4.13.1,2
(assuming 4.13.3 really does fix it)


-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital 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] [telemetry] [requirements] [FFE] Oslo.db 4.13.2

[Ihar Hrachyshka]

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  wrote:


On 09/07/2016 07:44 PM, Joshua Harlow wrote:



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





signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [telemetry] [requirements] [FFE] Oslo.db 4.13.2

[Matthew Thode]

On 09/07/2016 07:44 PM, Joshua Harlow wrote:
> 
>>
>> 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-requ...@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)



signature.asc
Description: OpenPGP digital 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] [telemetry] [requirements] [FFE] Oslo.db 4.13.2

[Tony Breeds]

On Wed, Sep 07, 2016 at 01:29:35PM -0400, Doug Hellmann wrote:
> What do we have that uses oslo.db and is itself a library that would
> need to be re-released?

Package  : oslo-db [oslo-db>=4.10.0] (used by 40 projects)
Re-Release   : 1 projects
openstack/neutron-lib [type:library]
Included in  : 20 projects
openstack/cinder  [type:service]
openstack/congress[type:service]
openstack/designate   [type:service]
openstack/glance  [type:service]
openstack/heat[type:service]
openstack/ironic  [type:service]
openstack/karbor  [type:service]
openstack/keystone[type:service]
openstack/magnum  [type:service]
openstack/manila  [type:service]
openstack/mistral [type:service]
openstack/murano  [type:service]
openstack/neutron [type:service]
openstack/nova[type:service]
openstack/sahara  [type:service]
openstack/senlin  [type:service]
openstack/solum   [type:service]
openstack/tacker  [type:service]
openstack/trove   [type:service]
openstack/watcher [type:service]
Also affects : 19 projects
openstack/astara  [release:cycle-with-milestones]
openstack/cue []
openstack/dragonflow  [release:independent]
openstack/ec2-api [release:independent]
openstack/gce-api []
openstack/ironic-inspector[release:cycle-with-intermediary]
openstack/kingbird[]
openstack/kosmos  []
openstack/networking-bagpipe  [release:independent]
openstack/networking-sfc  [release:independent]
openstack/neutron-dynamic-routing [release:cycle-with-milestones]
openstack/neutron-fwaas   [release:cycle-with-milestones]
openstack/neutron-lbaas   [release:cycle-with-milestones]
openstack/neutron-vpnaas  [release:cycle-with-milestones]
openstack/nimble  []
openstack/octavia [release:independent]
openstack/tricircle   []
openstack/vmware-nsx  []
openstack/zun []

A patch bump in neutron-lib will affect 19 projects but doesn't require a
another g-r change

I've updated https://review.openstack.org/365565 Can we get +1's from the
Release managers and Neutron ?

Yours Tony.


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] [telemetry] [requirements] [FFE] Oslo.db 4.13.2

[Joshua Harlow]

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

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

[Doug Hellmann]

Excerpts from Mike Bayer's message of 2016-09-07 14:09:06 -0400:
> 
> On 09/07/2016 01:29 PM, Doug Hellmann wrote:
> > Excerpts from Matthew Thode's message of 2016-09-07 09:11:58 -0500:
> >> On 09/07/2016 08:58 AM, Doug Hellmann wrote:
> >>> Excerpts from Matthew Thode's message of 2016-09-07 08:21:50 -0500:
>  https://review.openstack.org/366298
> 
>  This is just a bump to upper-constraints so is more minor to get testing
>  working and fix the bug that occurred in Gnocchi (and possibly others).
> 
>  We are able to mask the 'bad' versions of oslo.db and unmask pymysql
>  0.7.7 after the freeze (and backport them to stable/newton) so this is
>  easier to merge.
> 
> >>>
> >>> If we have a known-bad version of the library, maybe it would be better
> >>> to incorporate that info into the global-requirements list before we
> >>> branch the requirements repository? I'm not sure what we've done in
> >>> this case for past cycles.
> >>>
> >>> Doug
> >>>
> >>> __
> >>> 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
> >>>
> >> Are you fine with the knock on effects that a gr update would cause?
> >
> > What do we have that uses oslo.db and is itself a library that would
> > need to be re-released?
> 
> I would assume Gnocchi which acts as a backend for Ceilometer.

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.

Doug

__
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] [telemetry] [requirements] [FFE] Oslo.db 4.13.2

[Mike Bayer]

On 09/07/2016 01:29 PM, Doug Hellmann wrote:

Excerpts from Matthew Thode's message of 2016-09-07 09:11:58 -0500:

On 09/07/2016 08:58 AM, Doug Hellmann wrote:

Excerpts from Matthew Thode's message of 2016-09-07 08:21:50 -0500:

https://review.openstack.org/366298

This is just a bump to upper-constraints so is more minor to get testing
working and fix the bug that occurred in Gnocchi (and possibly others).

We are able to mask the 'bad' versions of oslo.db and unmask pymysql
0.7.7 after the freeze (and backport them to stable/newton) so this is
easier to merge.



If we have a known-bad version of the library, maybe it would be better
to incorporate that info into the global-requirements list before we
branch the requirements repository? I'm not sure what we've done in
this case for past cycles.

Doug

__
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


Are you fine with the knock on effects that a gr update would cause?


What do we have that uses oslo.db and is itself a library that would
need to be re-released?


I would assume Gnocchi which acts as a backend for Ceilometer.





Doug

__
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

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

[Doug Hellmann]

Excerpts from Matthew Thode's message of 2016-09-07 09:11:58 -0500:
> On 09/07/2016 08:58 AM, Doug Hellmann wrote:
> > Excerpts from Matthew Thode's message of 2016-09-07 08:21:50 -0500:
> >> https://review.openstack.org/366298
> >>
> >> This is just a bump to upper-constraints so is more minor to get testing
> >> working and fix the bug that occurred in Gnocchi (and possibly others).
> >>
> >> We are able to mask the 'bad' versions of oslo.db and unmask pymysql
> >> 0.7.7 after the freeze (and backport them to stable/newton) so this is
> >> easier to merge.
> >>
> > 
> > If we have a known-bad version of the library, maybe it would be better
> > to incorporate that info into the global-requirements list before we
> > branch the requirements repository? I'm not sure what we've done in
> > this case for past cycles.
> > 
> > Doug
> > 
> > __
> > 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
> > 
> Are you fine with the knock on effects that a gr update would cause?

What do we have that uses oslo.db and is itself a library that would
need to be re-released?

Doug

__
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] [telemetry] [requirements] [FFE] Oslo.db 4.13.2

[gordon chung]

just a heads up, oslo.db 4.13.2 is also broken. we will need this: 
https://review.openstack.org/#/c/366362/ or something that fixes issue :)

On 07/09/16 09:21 AM, Matthew Thode wrote:
> https://review.openstack.org/366298
>
> This is just a bump to upper-constraints so is more minor to get testing
> working and fix the bug that occurred in Gnocchi (and possibly others).
>
> We are able to mask the 'bad' versions of oslo.db and unmask pymysql
> 0.7.7 after the freeze (and backport them to stable/newton) so this is
> easier to merge.
>
>
>
>
> __
> 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
>

-- 
gord

__
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] [telemetry] [requirements] [FFE] Oslo.db 4.13.2

[Matthew Thode]

On 09/07/2016 08:58 AM, Doug Hellmann wrote:
> Excerpts from Matthew Thode's message of 2016-09-07 08:21:50 -0500:
>> https://review.openstack.org/366298
>>
>> This is just a bump to upper-constraints so is more minor to get testing
>> working and fix the bug that occurred in Gnocchi (and possibly others).
>>
>> We are able to mask the 'bad' versions of oslo.db and unmask pymysql
>> 0.7.7 after the freeze (and backport them to stable/newton) so this is
>> easier to merge.
>>
> 
> If we have a known-bad version of the library, maybe it would be better
> to incorporate that info into the global-requirements list before we
> branch the requirements repository? I'm not sure what we've done in
> this case for past cycles.
> 
> Doug
> 
> __
> 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
> 
Are you fine with the knock on effects that a gr update would cause?

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital 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] [telemetry] [requirements] [FFE] Oslo.db 4.13.2

[Doug Hellmann]

Excerpts from Matthew Thode's message of 2016-09-07 08:21:50 -0500:
> https://review.openstack.org/366298
> 
> This is just a bump to upper-constraints so is more minor to get testing
> working and fix the bug that occurred in Gnocchi (and possibly others).
> 
> We are able to mask the 'bad' versions of oslo.db and unmask pymysql
> 0.7.7 after the freeze (and backport them to stable/newton) so this is
> easier to merge.
> 

If we have a known-bad version of the library, maybe it would be better
to incorporate that info into the global-requirements list before we
branch the requirements repository? I'm not sure what we've done in
this case for past cycles.

Doug

__
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] [telemetry] [requirements] [FFE] Oslo.db 4.13.2

[Matthew Thode]

https://review.openstack.org/366298

This is just a bump to upper-constraints so is more minor to get testing
working and fix the bug that occurred in Gnocchi (and possibly others).

We are able to mask the 'bad' versions of oslo.db and unmask pymysql
0.7.7 after the freeze (and backport them to stable/newton) so this is
easier to merge.


-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital 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