On Wed, Oct 7, 2020 at 11:54 AM Roy Smith roy@panix.com wrote:
It would be really good if the bastions could be updated to something more modern, so we could have a uniform python infrastructure everywhere. I think I once opened a phab ticket for this, which was closed as some variation on infeasible.
I ran into exactly the issue described below myself. After trying a bunch of various workarounds, I ended up building my own python 3.7 from source. That's suboptimal in so many ways, but it was the only way I could find to get a consistent setup between my test/dev environment on the bastion and my production environment on kubernetes.
Use a `webservice python3.7 shell` session as your dev/test environment and you will a) get the same python version as the "production" container, and b) move your dev/test workload off of the limited resources of the bastion server and onto the more scalable Kubernetes cluster.
At some point, this is going to become a more acute problem, since 3.5 is officially end-of-life.
The bastions in Toolforge need to be compatible with the Grid Engine cluster because they act as job submission hosts for the grid. Today, the grid engine cluster is running Debian Stretch as its base operating system [0]. Debian Stretch is a supported release through June 2022. There is currently no scheduled work to rebuild and replace the Debian Stretch instances in Toolforge, but rest assured that this work will happen before the end of life of Debian Stretch. I expect that the Toolforge admin team will start discussing the work needed to rebuild the Toolforge bastions and grid engine instances sometime after the Debian project releases their next stable version, Bullseye [1].
[0]: https://wikitech.wikimedia.org/wiki/News/Toolforge_Trusty_deprecation [1]: https://www.debian.org/releases/bullseye/
Bryan