User:DWalden (WMF)/Test2wiki k8s migration

Scope of change

The parts of the application that will be running in Kubernetes are highlighted in red in the below diagram.

Test when we touch the app server, for example:
- load a page
- submit a form
- make an API request
- back-end processing (deferred updates, jobs)
- features which call external binaries (see #Next_steps)
Don't worry about UI parts of the application
- unless they are making API requests in the backend (e.g. we might want to test VE as it relies on calls to parsoid)

Do the individual docker images function?
- MediaWiki + extensions
- Back-end processing (Jobs, Deferred updates)
- External binaries (Shellbox)
Do the docker images have access to the appropriate resources inside Kubernetes?
- What features rely on other resources like files, keystores, etc.
Do the docker images contest for resources inside Kubernetes?
Does it have access to resources outside Kubernetes?
- Things inside our ecosystem but outside Kubernetes (e.g. database, APIs, Parsoid)
- External services (outside our ecosystem)
Reliability, performance, load, stress...

Get Selenium tests running on test2wiki to provide smoke tests (phab:T303739).
~~Get API tests running against test2wiki.~~ Because running the API tests requires having test2wiki's $wgSecretKey, it is not possible to do so for security reasons.
Fill out the readiness reviews for teams #Team_testing_readiness.
- Decide what to do with features not covered by any team #Teams_or_features_not_covered_above.

Do we need to test that whatever load balancing solution we are using is working?
Do we test rolling back changes to test2wiki?
What testing do we need in terms of:
- reliability (e.g. concurrency)
- performance
- load
- anything else

(Making a page for a team not listed below? Use /Readiness_template)

(Want a high-level view? See /Readiness_high-level)

(Also see /How_to)

(Also, to see what is already installed on test2wiki, see https://test2.wikipedia.org/wiki/Special:Version)