Open Stack

On Wed, Oct 23, 2019 at 02:08:38PM -0500, Ghanshyam Mann wrote:
> Hello Everyone,
> 
> We are in Ussuri development cycle which is planned to drop the py2.7 support[1].
> 
> I was holding and planning to support the py2.7 in Tempest due to its branchless model[2]. My main point
> to keep py2 support is if any users running the Tempest on py27 env cloud and not in virtual env then they
> can keep running in the same way.  But this might be just me overthinking on this usage. 
> 
> What happens if we drop py2.7 from Tempest:
> * Users with the above case have the way to install the latest Tempest on virtual env of py3. or use 
>    the Tempest tag if they do not need latest Tempest.
> * No change in users using Tempest on py3 or in py3 virtual env.
> * Upstream testing of master or stable branch is no issue as we install the Tempest in virtual env.
>    Tempest in py3 venv can always test the py2.7 jobs.
> * other than that no change in Tempest usage or at least it would not break anything. 

I have made this exact argument before about venvs and tempest being not
actually part of a cloud installation (just in other contexts). In my
experience most people don't actually agree with it for whatever reason
(I assume because the installer/deployment projects treat tempest as the
same thing as other openstack projects). But I still feel that way and
even if some people don't agree there are still releases that support
python 2.7.

In general I'm in favor of just doing this though, as long as we didn't
already say that we'd continue supporting 2.7 somewhere in tempest
until the Train EM date. If we did advertise that anywhere then we'll
have to provide a deprecation period for those people who could have
latched onto that.

> 
> Why we cannot keep the support:
> There is no big cost of supporting the py2.7 in Tempest itself but that require Temepst dependency
> (OpenStack lib like Oslo and non-openstack maintained lib [3]) to keep supporting the py2.7 which is not
> feasible.

In my experience the list of requirements for tempest is not crazy long and
most of them don't have big api divergance (or at least how tempest uses
it). I'd almost say just set a version cap with python_version==2.7 to a
requirement when/if a requirement drops support for 2.7. Of course that
probably has g-r implications, not sure how that would work.

> 
> Other solution:
> One way is to cut the Tempest stable branch and keep the py2.7 support there with eligible backport from Tempest
> master which is py3 only. But I would say, QA team has no bandwidth to do so. if anyone wants to maintain that then
> we can discuss this option in more detail. 

Branching doesn't actually fix any of the harms you have outlined above. It just
increases the complexity of maintainence.

> 
> I have given a second thought on this and now ok to drop the py2.7 from Tempest by considering all the above points. 
> Please reply if any disagreement on this or add if anything I missed to consider. 
> 
> NOTE: Tempest includes its plugins also.

I don't actually buy this point, a plugin is independently maintained. If the
plugin maintainers do not want to support python 3 they don't have to. Just like
any other project that has an upstream dep that supports python 2.7 even if they
don't support it.

-Matt Treinish

> 
> [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010142.html
> [2] https://review.opendev.org/#/c/681203/
> [3] https://opendev.org/openstack/tempest/src/commit/7fdd39c6dbde37bccd419c4037e1e352a5189c5a/requirements.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20191023/2cdc693e/attachment.sig>