Page MenuHomePhabricator

Design mechanism and process for upgrading Kubernetes container runtimes
Open, Needs TriagePublic


Adding a new Docker image to the Toolforge Docker registry, making that image available to users of the webservice command, and eventually removing an older image that the new runtime replaces, should be a relatively easy and routine process.

We should have a standard practice that can be followed by the Toolforge admin team that is also well documented and publicized to the Toolforge end user community. This standard practice should include a basic timeline that can be repeated for each upgrade and what communication channels need to be used to advertise the changes.

The webservice cli should have a standard way of showing which runtimes are available and what their status is (something like: beta, stable, deprecated?). We probably should also have some consistent alias that can be used in tutorials and other documentation that would lead to a user building a brand new tool getting the current "stable" runtime so that we don't have to touch all of the docs each time a new version of the runtime for language X is promoted to stable.

See also

Event Timeline

bd808 created this task.Jan 13 2019, 12:11 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 13 2019, 12:11 AM

Implementing T195103: Add Support for Node.js 10 LTS to Toolforge could be used to design and document all of this.

bd808 renamed this task from Design mechanism and process for upgrading Kuberentes container runtimes to Design mechanism and process for upgrading Kubernetes container runtimes.Jan 13 2019, 12:27 AM
Bstorm added a subscriber: Bstorm.Jan 23 2019, 7:31 PM
Rillke added a subscriber: Rillke.Mar 4 2019, 1:22 PM