On Sat, Dec 12, 2015 at 10:27 PM Jeremy Stanley <[email protected]> wrote:
> On 2015-12-12 19:00:23 +0000 (+0000), Yuriy Taraday wrote: > > I think it should be a good first step in right direction. For example, > > with today's issue it would break gate for tempest itself only since all > > other jobs would have preinstalled tox reverted to one mentioned in > > upper-constraints. > [...] > > Other way around. It would force DevStack to downgrade tox if the > existing version on the worker were higher. Pretty much no other > jobs install tox during the job, so they rely entirely on the one > present on the system being correct and an entry for tox in > upper-constraints.txt wouldn't help them at all, whether they're > using that file to constrain their requirements lists or not (since > tox is not present in any of our projects' requirements lists). > By "other" jobs I meant all jobs that use devstack to install tempest. That's seem to be all jobs in all projects except probably tempest itself. As for jobs that don't use devstack but only run tox, I suggest us to add a step to adjust tox version according to upper-constraints as well. Also, the constraints list is built from pip installing everything > in global-requirements.txt into a virtualenv, so if tox is not a > direct or transitive requirement then it will end up dropped from > upper-constraints.txt on the next automated proposal in review. > Ok, will fix that in my CR.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
