Open Stack

 ---- On Mon, 19 Aug 2019 23:54:37 +0900 Matthew Treinish <mtreinish at kortar.org> wrote ----
 > On Sun, Aug 18, 2019 at 11:16:11AM -0500, Matthew Thode wrote:
 > > NOVA:
 > > lxml===4.4.1        nova tests fail https://bugs.launchpad.net/nova/+bug/1838666
 > > websockify===0.9.0  tempest test failing
 > > 
 > > KEYSTONE:
 > > oauthlib===3.1.0    keystone https://bugs.launchpad.net/keystone/+bug/1839393
 > > 
 > > NEUTRON:
 > > tenacity===5.1.1    https://2c976b5e9e9a7bed9985-82d79a041e998664bd1d0bc4b6e78332.ssl.cf2.rackcdn.com/677052/5/check/cross-neutron-py27/a0a3c75/testr_results.html.gz
 > >                     this could be caused by pytest===5.1.0 as well
 > > 
 > > KURYR:
 > > kubernetes===10.0.1 openshift PINS this, only kuryr-tempest-plugin deps on it
 > >                     https://review.opendev.org/665352
 > > 
 > > MISC:
 > > tornado===5.1.1     salt is cauing this, no eta on fix (same as the last year)
 > > stestr===2.5.0      needs merged https://github.com/mtreinish/stestr/pull/265
 > 
 > This actually doesn't fix the underlying issue blocking it here. PR 265 is for
 > fixing a compatibility issue with python 3.4, which we don't officially support
 > in stestr but was a simple fix. The blocker is actually not an stestr issue,
 > it's a testtools bug:
 > 
 > https://github.com/testing-cabal/testtools/issues/272
 > 
 > Where this is coming into play here is that stestr 2.5.0 switched to using an
 > internal test runner built off of stdlib unittest instead of testtools/subunit
 > for python 3. This was done to fix a huge number of compatibility issues people
 > had reported when trying to run stdlib unittest suites using stestr on
 > python >= 3.5 (which were caused by unittest2 and testools). The complication
 > for openstack (more specificially tempest) is that it's built off of testtools
 > not stdlib unittest. So when tempest raises 'self.skipException' as part of
 > it's class level skip checks testtools raises 'unittest2.case.SkipTest' instead
 > of 'unittest.case.SkipTest'. stdlib unittest does not understand what that is
 > and treats it as an unhandled exception which is a test failure, instead of the
 > intended skip result. [1] This is actually a general bug and will come up whenever
 > anyone tries to use stdlib unittest to run tempest. We need to come up with a
 > fix for this problem in testtools [2] or just workaround it in tempest.
 > 
 > [1] skip decorators typically aren't effected by this because they set an
 > attribute that gets checked before the test method is executed instead of
 > relying on an exception, which is why this is mostly only an issue for tempest
 > because it does a lot of run time skips via exceptions.
 > 
 > [2] testtools is mostly unmaintained at this point, I was recently granted
 > merge access but haven't had much free time to actively maintain it

Thanks matt for details. As you know, for Tempest where we need to support py2.7
(including unitest2 use) for stable branches, we are going to use the specific stetsr
version/branch(<when you will remove the py27 support) so fixing it on testtools side
is good option to me. I think your PR to remove the unittest2 use form testtools
make sense to me [1].  A workaround in Tempest can be last option for us.

Till we fix it and to avoid gate break, can we cap stestr in g-r  - stestr<2.5.0 ? I know that is
not the options you like.

[1] https://github.com/mtreinish/testtools/commit/38fc9a9e302f68d471d7b097c7327b4ff7348790

-gmann

 > 
 > -Matt Treinish
 > 
 > > jsonschema===3.0.2  see https://review.opendev.org/649789
 > > 
 > > I'm trying to get this in place as we are getting closer to the
 > > requirements freeze (sept 9th-13th).  Any help clearing up these bugs
 > > would be appreciated.
 > > 
 > > -- 
 > > Matthew Thode
 > 
 > 
 >