User:DWalden (WMF)/Test2wiki k8s migration/Search

What possible risks are posed to this feature by the k8s migration?
Not clear

What are the dependencies?
job queues, systemd timers (aka cron jobs). It's not clear if those are moving to k8s as part of this, or if they will continue through the existing infrastructure until a later date.

Other mediawiki extensions:
 * TimedMediaHandler
 * PdfHandler
 * SiteMatrix
 * PoolCounter
 * GeoData
 * Interwiki
 * WikimediaEvents

Also requires ability to make api requests from one wiki to another wiki.

Does it use any external services?
Elasticsearch

Is there any back-end processing?
Some through systemd timers that run daily. Lots of jobs. The remainder talks to elasticsearch directly and shouldn't be impacted.

Does it use external binaries?
Not directly. Depends on external binaries invoked during wikitext parsing through TimedMediaHandler, PdfHandler, maybe others.

Does it read or write files on the filesystem?
Not inside mediawiki.

Is there a regression or smoke testing strategy?
Sort-of, the @smoke tag of CirrusSearch tests/integration/ does very minimal checks, but it mostly amounts to "this thing isn't 100% broken" and typically fails due to UI changes made outside CirrusSearch. See selenium-daily-beta-CirrusSearch in jenkins.

Does it cover the dependencies mentioned above?
No

Can it be tested on test2wiki?
Top level functionality can be tested. Most cross-wiki integration is likely hard to test.

Is it feasible to make it testable on test2wiki?
Not clear. test2wiki would need sister wikis (wiktionary, wikipedia, wikiquote, etc.)