Page MenuHomePhabricator

toolforge: Update python image to Stretch
Closed, ResolvedPublic

Description

The python image is based on Jessie which includes an almost EOL'ed version of Python.

We should use the Stretch base image.

Event Timeline

GTirloni triaged this task as High priority.Mar 24 2019, 11:09 AM
GTirloni created this task.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 24 2019, 11:09 AM

The python35 image is based on Stretch, so we should decide what do to for the default python image. Is the policy to create new versioned images and let python get deprecated?

Danmichaelo added a subscriber: Danmichaelo.

Additionally, as pointed by @Danmichaelo, python35 is missing from webservice:

$ webservice --help
usage: webservice [-h] [--backend {gridengine,kubernetes}]
                  [type] {start,stop,status,restart,shell} [extra_args]

Online documentation: https://wikitech.wikimedia.org/wiki/Help:Toolforge/Web

Supported webservice types:
Kubernetes backend:  golang, jdk8, nodejs, php5.6 (default), php7.2, python,
                     python2, ruby2, tcl
Grid Engine backend: generic, lighttpd (default), lighttpd-plain, nodejs,
                     tomcat, uwsgi-plain, uwsgi-python

I think this might be a WIP task, CC @bd808

As pointed out by @Chicocvenancio, this was also mentioned in http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-cloud/20190322.txt :

[18:01:56] <bd.808>     pin.toch: we have a python3.5 Kuberentes container built, but it is not exposed for use yet. I expect to make it available in the first week of April
bd808 claimed this task.Mar 24 2019, 8:17 PM
bd808 moved this task from Triage to In Progress on the Toolforge board.Mar 25 2019, 10:57 PM
GTirloni removed a subscriber: GTirloni.Apr 3 2019, 10:17 AM

Python 3.4 is now no longer supported by upstream; one consequence is that mypy has dropped support for it, making my CI build for a tool fail. Until this task is resolved, I believe the only options I have are to not run mypy in CI anymore, or to run CI against a different version of Python than the one that will ultimately be used on Toolforge. I don’t really like either option, so I hope this task will be resolved soon :)

Python 3.4 is now no longer supported by upstream; one consequence is that mypy has dropped support for it, making my CI build for a tool fail.

It seems mypy is installed through pip, so another option could be to pin the mypy version to one that still supports 3.4.

True, that works as well. Thanks!

Yury_Bulka added a subscriber: Yury_Bulka.EditedApr 29 2019, 11:09 PM

This is especially confusing given that python3 --version returns 3.5.3 when logging in to tool forge and becomeing the tool user.

Having seen that, I happily dropped django 2.0 which was EOL'd in April (and was the last version to support python 3.4) in my tool, assuming that python on toolforge has been upgraded to 3.5.

Please, make python 3.5 available. Running on EOL'd stack is no fun (especially if you are a volunteer with a regular job).

bd808 added a comment.May 19 2019, 9:25 AM
$ webservice --backend=kubernetes python3.5 shell
Defaulting container name to interactive.
Use 'kubectl describe pod/interactive -n bd808-test' to see all of the containers in this pod.
If you don't see a command prompt, try pressing enter.
$ python3 --version
Python 3.5.3
$ logout
Session ended, resume using 'kubectl attach interactive -c interactive -i -t' command when the pod is running
Pod stopped. Session cannot be resumed.

Thanks a lot, @bd808! I've already upgraded my tool to the python3.5 image.

bd808 closed this task as Resolved.May 19 2019, 9:50 AM