This is a follow-up to T310435.
That task introduced a change to the fonts installed in the php74 Toolforge Kubernetes image, which solved SVG Translate's issues but introduced complexity for managing the images.
Questions to answer:
The less expensive fix in case the font change is reverted would just be to move back to running the webservice on the Toolforge grid engine. I will personally guarantee that there will be a solution for adding custom apt packages to tools running on the Toolforge kubernetes cluster before the Toolforge grid engine is decommissioned. Y'all are awesome for trying over and over to move off of legacy systems, but as in 2019 (T213669) the state of the "better" systems is not quite what all tools need yet.
@bd808 Is there a ticket related to this that we can wait for? Would you mind letting us know when this is resolved?
There is not currently a ticket. There is an ongoing discussion happening on the cloud-admin@lists.wikimedia.org mailing list. I can and will commit to keeping y'all informed about that discussion's decisions that affect the svgtranslate tool. Would posting updates on this ticket be a reasonable way to let folks who are interested in knowing what those decisions are know about them?
Would posting updates on this ticket be a reasonable way to let folks who are interested in knowing what those decisions are know about them?
For us, yes, certainly. I'm not sure if the decision warrants broader attention on cloud-announce or not.
For the record, I personally am in favor of moving to VPS. Our team is very experienced with it. What worries me is if we keep the change to the php74 image, what happens when we need to upgrade to a newer PHP? Will Cloud Services know to adopt this to other versions or will have to go through this again every N years? Of course, once we are able to use our own images on Toolforge, there will be no concern (as far as fonts), but I'm assuming that's still "a ways" away.
Some global announce will likely happen as well, but in all practicality the change I made for T310435: Korean characters rendered as Unicode boxes in the SVG Translate Tool preview (due to lack of fonts) was for svgtranslate alone (and that's why there is a discussion about reverting this special treatment).
For the record, I personally am in favor of moving to VPS. Our team is very experienced with it.
That's your prerogative of course. You already know that keeping a VPS instance running is almost always more toil than keeping a Toolforge tool running.
What worries me is if we keep the change to the php74 image, what happens when we need to upgrade to a newer PHP? Will Cloud Services know to adopt this to other versions or will have to go through this again every N years? Of course, once we are able to use our own images on Toolforge, there will be no concern (as far as fonts), but I'm assuming that's still "a ways" away.
I would expect the fonts to be carried forward if they are not reverted and if there is ever another set of centrally managed PHP runtime docker containers created. There are currently 3 engineers working on Toolforge Build Service and it is seen as a blocker to completing Grid-Engine-to-K8s-Migration which has been given high priority in WMCS planning. Forecasting the completion date of a complex feature like Toolforge Build Service is difficult, but I would honestly be quite surprised if it is not in general use by the end of the Foundation's 22/23 fiscal year. I would not be overly surprised if a call for beta testers comes in January-March 2023.
Per https://lists.wikimedia.org/hyperkitty/list/cloud-admin@lists.wikimedia.org/message/6IS7OPBF35VDFGP3OSM7OV6GWAXJAMTS/ I think I can now say that the fonts will remain available for svgtranslate in the php7.4 image. I also believe that if there is another generation of PHP images following 7.4 they will also include the fonts. "If there is another generation" meaning if we don't have a buildpack system to replace these images before having a good way to deliver newer PHP versions. Once buildpacks are generally available I expect that WMCS will start working to phase out the current static images and their management.
Alright, with that I think we can consider this resolved. Many thanks to you and all of WMCS!