Open Stack

 ---- On Fri, 17 Jan 2020 05:51:28 -0600 Bernard Cafarelli <bcafarel at redhat.com> wrote ----
 > On Fri, 17 Jan 2020 at 12:01, Slawek Kaplonski <skaplons at redhat.com> wrote:
 > Hi,
 > 
 > > On 17 Jan 2020, at 11:14, Bernard Cafarelli <bcafarel at redhat.com> wrote:
 > > 
 > > On Fri, 17 Jan 2020 at 05:11, Jeremy Stanley <fungi at yuggoth.org> wrote:
 > > On 2020-01-16 22:02:05 -0600 (-0600), Ghanshyam Mann wrote:
 > > [...]
 > > > Second option is to install the tempest and plugins in py3 env on
 > > > py2 jobs also. This should be an easy and preferred way.
 > > [...]
 > > 
 > > This makes more sense anyway. Tempest and its plug-ins are already
 > > segregated from the system with a virtualenv due to conflicts with
 > > stable branch requirements, so hopefully switching that virtualenv
 > > to Python 3.x for all jobs is trivial (but I won't be surprised to
 > > learn there are subtle challenges hidden just beneath the surface).
 > > 
 > > That sounds good for supported releases. Once we have them back in working order, I wonder how it will turn out for queens.
 > > In neutron, there is a recent failure [1] as this EM branch now uses a pinned version of the plugin. The fix there is most likely to also pin tempest - to queens-em [2] but then will also require some fix for the EOLing python2 drama.
 > 
 > But if we will use for queens branch tempest pinned to queens-em tag, we shouldn’t have any such problems there as all requirements will be also used from queens branch, or am I missing something here?
 > Sadly not, from what I read in attempt [1] to limit neutron-lib to "old" version. And I see the same error in a test run with pinned tempest [2]:2020-01-16 14:44:18.741517 | controller | 2020-01-16 14:44:18.741 | Collecting neutron-lib===2.0.0 (from -c u-c-m.txt (line 79))
 > 2020-01-16 14:44:19.023699 | controller | 2020-01-16 14:44:19.023 |   Could not find a version that satisfies the requirement neutron-lib===2.0.0 (from -c u-c-m.txt (line 79)) (from versions: 0.0.1, 0.0.2, 0.0.3, 0.1.0, 0.2.0, 0.3.0, 0.4.0, 1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.9.1, 1.9.2, 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.14.0, 1.15.0, 1.16.0, 1.17.0, 1.18.0, 1.19.0, 1.20.0, 1.21.0, 1.22.0, 1.23.0, 1.24.0, 1.25.0, 1.26.0, 1.27.0, 1.28.0, 1.29.0, 1.29.1, 1.30.0, 1.31.0)
 > 2020-01-16 14:44:19.042505 | controller | 2020-01-16 14:44:19.042 | No matching distribution found for neutron-lib===2.0.0 (from -c u-c-m.txt (line 79))

Yes, Temepst venv uses the upper constraint from master always. We need to cap the u-c also accordingly. I did not do for Ocata/Pike
case which I will fix as they can start failing any time. For Tempest, it is straight forward where u-c has to be used of the branch corresponding
to pin Tempest.  But for plugins, it is complex. All tempest plugins are being installed one by one un single logic in devstack so using different
constraint for different plugins might not be possible (there should not be much cases like that where job tests more than one plugins tests
but there are few).

Best possible solution I can think of is to cap all the Tempest plugins together with Tempest and use corresponding stable branch u-c.  Or
we modify devstack logic with if-else condition for plugins require cap and rest else will be master. Any other thought?

-gmann

 > 
 > [1] https://review.opendev.org/702986/[2] https://review.opendev.org/#/c/701900/ https://zuul.opendev.org/t/openstack/build/ee8021c1470a4fb88f55d64cc16ed15e
 > > 
 > > As tempest is branchless, it looks like if we want to keep neutron-tempest-plugin tests for queens we will rather need solution 1 for this branch? (but let's focus first on getting the supported branches back in working order)
 > > 
 > > [1] https://bugs.launchpad.net/neutron/+bug/1859988 
 > > [2] https://review.opendev.org/702868
 > 
 > 
 > -- 
 > Bernard Cafarelli
 >