This email contains valuable information about the Toolforge service.
Starting today, we're initiating a process to migrate away from Debian
Stretch to Debian Buster for all of Toolforge servers, and the most
affected piece is the Grid Engine backend in particular.
Debian Stretch was released in June 2017, and long term support for it
(including security updates) will cease in June 2022. We need to shut
down all Stretch hosts before the end of support date to ensure that
Toolforge remains a secure platform. This migration will take several
months because many people still use the Stretch hosts and our users
are working on tools in their spare time.
You should be aware that our ultimate goal is to deprecate Grid Engine
entirely and replace it with Kubernetes. Read below for more information
== Initial timeline ==
Subject to change, see Wikitech for living timeline.
* 2022-02-15: Availability of Debian Buster grid announced to community
* 2022-03-21: Weekly reminders via email to tool maintainers for tools
still running on Stretch
* Week of 2022-04-21:
** Daily reminders via email to tool maintainers for tools still running on
** Switch login.toolforge.org to point to Buster bastion
* Week of 2022-05-02: Evaluate migration status and formulate plan for
final shutdown of Stretch grid
* Week of 2022-05-21: Shut down Stretch grid
== What is changing? ==
* New bastion hosts running Debian Buster with connectivity to the new job
* New versions of PHP, Python3, and other language runtimes
* New versions of various support libraries
== What should I do? ==
You should migrate your Toolforge tool to a newer environment.
You have two options:
* migrate from Toolforge Stretch Grid Engine to Toolforge Kubernetes.
* migrate from Toolforge Stretch Grid Engine to Toolforge Buster Grid
The Cloud Services team has created the Toolforge Stretch
deprecation page on wikitech.wikimedia.org to document basic steps
needed to move web services, cron jobs, and continuous jobs from the
old Stretch grid to the new Buster grid. That page also provides more
details on the language runtime and library version changes and will
provide answers to common problems people encounter as we find them.
If the answer to your problem isn't on the wiki, ask for help using
any of our communication channels.
We encourage you to move to Kubernetes today if you can, see below for
For those who can't migrate to Kubernetes, the Debian Buster grid should
be adopted within the next three months.
== A note on the future of Toolforge, the Grid and Kubernetes ==
As of today, Toolforge is powered by both Grid Engine and Kubernetes.
For a number of reasons, we have decided to deprecate Grid Engine and
replace all of its functions with Kubernetes. We're not yet ready to
offer all grid-like features on Kubernetes, but we're working on it.
As soon as we are able, we will begin the process of migrating the
workloads and shutting down the grid. This is something we hope to do
between 2022 and 2023.
We share this information to encourage you to evaluate migrating your
tool away from Grid Engine to Kubernetes.
One of the most prominent missing features on Kubernetes was a friendly
command line interface to schedule jobs (like jsub). We've been working
on that, and have a beta-level interface that you can try today: the
Toolforge jobs framework .
Seyram Komla Sapaty
Wikimedia Cloud Services
Cloud-announce mailing list -- cloud-announce(a)lists.wikimedia.org
List information: https://lists.wikimedia.org/postorius/lists/cloud-announce.lists.wikimedia.…
Hello. Yesterday, I started scheduling my cron jobs on the grid with the
`--release buster` option (previously was defaulting to Stretch). I have
gotten dozens of "Someone (probably you) recently logged in to your account
from a new device" notifications since then. Can I do anything to stop this
other than disable those notifications altogether?
I'm running Django 3.1 and social-auth-app-django 3.1.0 so I can authenticate against MediaWiki. Everything works, but want to start moving toward more modern releases. If I upgrade social-auth-app-django to anything newer, I get an exception in the authentication flow:
Direct assignment to the forward side of a many-to-many set is prohibited. Use groups.set() instead.
Has anybody else seen this problem?
It looks like this was first reported about 18 months ago <https://github.com/python-social-auth/social-app-django/issues/256>, with no response to the issue. I fear that the whole python-social-auth project is close to abandoned. There's been a total of 4 commits in the last 6 months. Unfortunately, I'm not aware of any viable alternative.