On 18 November 2015 at 16:27, Matt Riedemann <mriedem at linux.vnet.ibm.com> wrote: > > > On 11/17/2015 9:22 PM, Matt Riedemann wrote: >> >> I noticed this failing today: >> >> >> http://logs.openstack.org/81/206681/3/check/gate-trove-python27/45d645d/console.html#_2015-11-17_17_07_28_061 >> >> >> Looks like https://review.openstack.org/#/c/218701/ and maybe the >> dependent python-troveclient change would need to be backported to >> stable/kilo (neither are clean backports), or we can just skip the test >> on stable/kilo if there is a good reason why it won't work. >> > > I also see that the unit test job on stable/kilo is pulling in trunk > python-troveclient: > > http://logs.openstack.org/81/206681/3/check/gate-trove-python27/45d645d/console.html#_2015-11-17_17_07_28_393 > > Even though we have troveclient capped at 1.1.0 in kilo g-r: > > https://github.com/openstack/requirements/blob/stable/kilo/global-requirements.txt#L136 > > So how is that happening? > > Oh, because of this: > > https://github.com/openstack/trove/blob/stable/kilo/test-requirements.txt#L17 > > And that's terrible....why are we doing that? I know you know this, but yeah - don't do that :). FWIW constraints *will* override that but liberty and above. -Rob -- Robert Collins <rbtcollins at hp.com> Distinguished Technologist HP Converged Cloud