---- On Mon, 15 Apr 2019 08:35:36 -0500 Moises Guimaraes de Medeiros <moguimar@redhat.com> wrote ----

Hi Ghanshyam, I saw your patch on oslo.config and I notice that in the tox.ini file it drops Python 3 at all. Should we add py36 in the same patch before approving it? I'm sending this here cause it might also be the same case for other patches.

I did not explicitly added the py36 tox env in same patch which was not there. I thought it is intentional from the project side. But yeah we can modify the py35 env to py36 if there is no. -gmann

Em dom, 14 de abr de 2019 às 20:48, Ghanshyam Mann <gmann@ghanshyammann.com> escreveu:

-- Thanks,Moisés Guimarães Hello Everyone,

All the integration testing has been moved to Bionic[1] now and as discussed in the TC meeting[2], we are good to drop the py35 testing.

Train: Good to drop. I am going to push the patches to remove the py35 jobs from the master (which is Train now).

Stable/Stein: Ok to drop if the project wants. Stable/Stein gate is also moved to Bionic so we are good to drop py35 from stable/stein too. But backporting all the patches will be too many patches for projects to merge on stable/stein so we discussed not to propose all of them to stable/stein. If the project really wants to drop it from stable/stein then, they can backport.

NOTE: Till stable/rocky, we should keep testing py35. If your project is branchless like Tempest and gate the same jobs for stable/rocky or older then, you should keep testing the py35 until stable/rocky EOL.

[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004647.htm... [2] http://eavesdrop.openstack.org/meetings/tc_python3/2019/tc_python3.2019-03-0... http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003610.htm...

-gmann

...

we are good to drop the py35 testing.

Train: Good to drop. I am going to push the patches to remove the py35 jobs from the master (which is Train now). so i asked this a number of months ago and at the time i did not get a concreate answer. if we drop py35 testing that means we are increaseing our minium python 3 version to py36

Yes, following our policy of using the python version supported on the distros we target at the beginning of the cycle. the Stein minimum py3 version was Python 3.6 [0].

so projects are free to use python 3.6 only feature correct once py2.7 support is removed.

Dropping py2 support is currently planned for the U release cycle.

i recently found out that nova does not work on py37 and if we have no testing for py35 then its possible that we could also break there so if this goes ahead i want to carify that for train the only supported python veriosn will by py27 and py36 unless we elect to add py37 support as a train goal.

...

Failures on py3.7 will need to be addressed as that is one of the Python runtimes required for Train [1]. [0] https://governance.openstack.org/tc/reference/runtimes/stein.html [1] https://governance.openstack.org/tc/reference/runtimes/train.html

On Mon, 2019-04-15 at 09:21 -0500, Sean McGinnis wrote:

...

...

we are good to drop the py35 testing.

Train: Good to drop. I am going to push the patches to remove the py35 jobs from the master (which is Train now).

so i asked this a number of months ago and at the time i did not get a concreate answer. if we drop py35 testing that means we are increaseing our minium python 3 version to py36

Yes, following our policy of using the python version supported on the distros we target at the beginning of the cycle. the Stein minimum py3 version was Python 3.6 [0]. ok so we should we update teh setup cfg markers to reflect that? we still state 3.5 on nova master https://github.com/openstack/nova/blob/78e742662edd164c46382c31e106884762fed...

...

so projects are free to use python 3.6 only feature correct once py2.7 support is removed.

Dropping py2 support is currently planned for the U release cycle.

yes i know what i was getting at is becauese we still have to support pyton 2.7 in train the subset of lanague feautres we can currently use is what is support on python 2.7 and also work son python 3.6 meaning we cannot use any python3 only feature until U.

...

i recently found out that nova does not work on py37 and if we have no testing for py35 then its possible that we could also break there so if this goes ahead i want to carify that for train the only supported python veriosn will by py27 and py36 unless we elect to add py37 support as a train goal.

...

Failures on py3.7 will need to be addressed as that is one of the Python runtimes required for Train [1].

i have not dug into the failure other than to know that the agent hangs or crashes when you boot a vm with no error messages of any kind in journalctl. so we will need to fix it but at this point it could be anything form eventlet not working properly to we have some python27/36 only code on the spawn codepath. the fact that even with devstack and debug loggin enabeld the output just stops makes i hard figure out whats actully going on but i also have not dug into it much yet.

[0] https://governance.openstack.org/tc/reference/runtimes/stein.html [1] https://governance.openstack.org/tc/reference/runtimes/train.html

---- On Mon, 15 Apr 2019 10:44:51 -0500 Ghanshyam Mann <gmann@ghanshyammann.com> wrote ----

---- On Mon, 15 Apr 2019 09:45:06 -0500 Zane Bitter <zbitter@redhat.com> wrote ----

...

On 14/04/19 2:48 PM, Ghanshyam Mann wrote:

...

Hello Everyone,

All the integration testing has been moved to Bionic[1] now and as discussed in the TC meeting[2], we are good to drop the py35 testing.

Train: Good to drop. I am going to push the patches to remove the py35 jobs from the master (which is Train now).

+1

Can I suggest that you instead push patches to switch to openstack-python3-train-jobs?

The only downside of that is that since it can't merge until py37 works, projects will end up continuing to run py35 tests until py37 support is ready to merge. But the upside is we only have to make one change for Train.

I was thinking to update the Train runtime targets in 'openstack-python-jobs' project template which is already present on each project side. If we use this template to update testing runtime jobs each cycle then, we do not need to update all projects.

Any drop of py version or addition will be done at a single place and with consistency.

Another reason I kept it separate from Train testing runtime is that if any project wants to backport py35 dropping to stable/stein then, they can do with this patchset. -gmann

-gmann

...

...

Stable/Stein: Ok to drop if the project wants. Stable/Stein gate is also moved to Bionic so we are good to drop py35 from stable/stein too. But backporting all the patches will be too many patches for projects to merge on stable/stein so we discussed not to propose all of them to stable/stein. If the project really wants to drop it from stable/stein then, they can backport.

NOTE: Till stable/rocky, we should keep testing py35. If your project is branchless like Tempest and gate the same jobs for stable/rocky or older then, you should keep testing the py35 until stable/rocky EOL.

[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004647.htm... [2] http://eavesdrop.openstack.org/meetings/tc_python3/2019/tc_python3.2019-03-0... http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003610.htm...

-gmann