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.



See also File:Presentation_qte_sync_20042022.pdf.

Scope of testing

 * 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 )
 * 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)

Risks

 * 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...

Next steps

 * Get Selenium tests running on test2wiki to provide smoke tests (T303739)
 * Decide what needs to be tested and how we will divide up the work
 * Might need to ask members of QTE team to enumerate the features/extensions their teams are responsible (as has already been done here for Growth and Structured Data teams T303479)
 * Features/extensions which use external binaries (e.g. gpg)
 * External binaries will now be run by calling an HTTP API (see T289225)
 * We need to find a way to enumerate all extensions that rely on external binaries
 * Need to properly setup test2wiki so we can test it (e.g. configs, test data)
 * Might need to ask members of QTE to evaluate the readiness of their features/extensions to be tested on test2wiki (again, like here T303479)

Open Questions

 * 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

Team testing readiness
(Making a new subpage? Use /Readiness_template) (Want a high-level view? See /Readiness_high-level)
 * /Anti-Harassment_Tools
 * /Editing
 * /Inuka
 * /Language
 * /Apps
 * /Trust_and_Safety_Tools
 * /Web_Readers

Teams or features not covered above
See Developers/Maintainers.

Teams or features that don't need testing coverage

 * Design_Systems_Team (nothing on production yet?)
 * Fundraising_tech (I am not sure about their technology stack)
 * Platform_Engineering_Team (I am not sure about this team)