[openstack-dev] [all] testtools 1.2.0 release breaks the world
robertc at robertcollins.net
Sat Nov 15 21:06:35 UTC 2014
On 16 November 2014 09:38, Dave Walker <email at daviey.com> wrote:
> On 15 November 2014 20:23, Robert Collins <robertc at robertcollins.net> wrote:
>> On 16 November 2014 09:03, Dave Walker <email at daviey.com> wrote:
>>> On 15 November 2014 19:51, Robert Collins <robertc at robertcollins.net> wrote:
>>>> It probably needs to be backed out of stable/icehouse. The issue is
>>>> that we were installing unittest2 via distro packages *and* testtools
>>>> new dependency on unittest2 did not express a minimum version.
>>>> We're just about to issue 1.2.1 which will have such a minimum version.
>>>> And for the record, this was released on saturday, not friday :).
>>> We've discussed this on IRC, but I fail to see how this is an
>>> appropriate fix for stable/* . This would mean introducing new minima
>>> to stable branches, which for stable branches is totally
>>> This causes the effect of both distros and deployers requiring a
>>> higher version which they have not planned for. If we pin
>>> oslo.messaging (which is what we started agreeing in Paris), this
>>> problems goes away.
>> Huh? I think you're working a different bug, no? The testtools thing
>> is what I thought this thread was about :) The
>> oslo.messaging/middleware thing is separate but both are happening at
>> the same time on juno/stable. I was only referring to backing out a
>> pin of testtools - which is needed because with single-version-tempest
>> we can't pin any of tempests dependencies in just stable, we have to
>> have the pins be consistent across all versions tested by tempest
>> (with the current install strategy).
> You are right, I accidently folded two issues into 1. However, I do
> not understand how we can resolve this issue the way you have outlined
> without introducing a new minimum version on unittest2, which was not
> previously a requirement on stable/*.
> This surely has the same effect that I outlined?
But stable MUST permit new requirements, or tempest cannot change
ever, since it must match the versions of the oldest release we're
grenading with master tempest. So saying 'stable tests can never
change requirements' is a non-starter, unless we change the way we're
installing tempest there, and if we do that the unittest stuff is only
applicable to tempest and thus irrelevant to the stable branches.
Robert Collins <rbtcollins at hp.com>
HP Converged Cloud
More information about the OpenStack-dev