The Content-Transform-Team uses parsoidtest1001 for weekly pre-train parsoid testing: we tag parsoid, then run round-trip tests on parsoid1001 against a read-only copy of the production database before releasing the tagged parsoid to mediawiki-vendor to ride the train.
Parsoidtest1001 is "almost entirely" a production mediawiki server.
As part of the PHP8.1 transition process, parsoidtest1001 should probably be switched to PHP 8.1 with the first group of test servers.
Thanks for writing this up, @cscott.
So, one alternative to migrating parsoidtest1001 to PHP 8.1 would be to instead provide a k8s-based alternative that fulfills the same use case, and is 8.1-based from day 1.
One notable benefit is that it would enable testing against either 7.4 or 8.1 at the user's choice for some period, rather than having a flag-day where the one-and-only parsoidtest1001 host switches to 8.1.
Functionally, this could be a CLI tool that allows one to start a "temporary" k8s pod running parsoid code checked out at a specific commit ref. For example, invoking the tool to create the pod would replace the ssh-fetch-checkout step in start-rt-test.sh (with functionality to address the pod also wired into the RT client unit). It should also be able to support manual / one-off tests similar to what's described here.
@cscott - Does that sound like something that would support your use cases?
Sketch: If we were to go this route, I think it should be fairly straightforward to model a "v0.1" of this on how mwscript-k8s works.
In addition to obvious differences like enabling httpd / php-fpm and running in a distinct namespace, the core difference would be an init-container that could clone / checkout the parsoid code at the desired commit ref into an emptyDir volume mounted at /srv/parsoid-testing (RO) in the mediawiki app container (noting that we'd also need to slightly update the mediawiki-config logic that loads the extension at the alternative path to properly detect this environment).
One clear benefit of continuing to use the "load the extension from an alternative path" approach is that it entirely side-steps container image builds.
One key assumption here is that we indeed want these pods to be temporary. If we instead want a single durable deployment that's more directly analogous to parsoidtest1001, then that's actually a bit easier - though we do need a way to durably specify the target commit ref for use by the init-container (e.g., in a config map).
I'm also happy to consider alternatives, particularly if we're close to finalizing a general solution for running experimental code (T324003). Also, I'm not sure if @akosiaris has already given this some thought given recent work on parsoidtest1001.
The high-level desired features are:
We source a file in the parsoid repo from mediawiki-config which allows us to customize the mediawiki configuration, although we don't use this often.
As optional features, being able to control the version of mediawiki-vendor and/or mediawiki-core is helpful.
Thank you very much, @cscott. I believe a solution like the one outlined in T380485#10355701 should satisfy the feature requirements in T380485#10384420 at least as well as the current setup on parsoidtest1001, and in some cases possibly better (e.g., higher fidelity to the current state of k8s-based production).
As far as I can tell, it also should not get in the way of the database user changes proposed in T298046, though I can't immediately speak to the other aspect of that task (ability to run with vendor from HEAD).
I think we're on board with that plan. Ideally we'd like to run with the existing parsoidtest1002 and the new PHP 8.x solution in parallel for as long as possible, so that we don't drop test coverage of the PHP 7.4 environment until we're ready for all of production to move to PHP 8.x, but we're ready to start testing on PHP 8.x as far as we know.
Thank you, @cscott!
Two additional questions while I'm sketching out some of the implementation details: