Page MenuHomePhabricator

ResourceLoader icon rasterization fails via MediaWiki-on-Kubernetes
Closed, ResolvedPublic

Description

Error
MediaWiki\ResourceLoader\Image::getImageData failed to rasterize for /srv/mediawiki/php-1.41.0-wmf.7/extensions/Echo/modules/icons/edit-user-talk-progressive.svg
Impact

Image is missing.

Notes

The failing requests have in common servergroup: kube-mw-web, and likewise with Kubernetes pods as host name:

  • mediawiki-main-57ddc5b8d5-85vm8
  • mediawiki-main-57ddc5b8d5-nwqsx
  • mediawiki-canary-7c9b55dd85-b6ngz
  • mediawiki-main-6676bbfcd8-2j7mr
  • mediawiki-canary-66db9c6946-dk6kf

The same URL on a wiki not via Kubernetes works fine:

https://aa.wikipedia.org/w/load.php?format=rasterized&image=edit-user-talk&lang=en&modules=ext.echo.emailicons

Event Timeline

Krinkle triaged this task as High priority.May 5 2023, 2:42 AM
Krinkle created this task.
Krinkle edited projects, added Performance-Team; removed Performance-Team (Radar).

I suspect there's a missing PHP extension or some other Debian package. Looking for ServiceOps to triage this further, I can help when needed.

Indeed. The code for resourceloader wants to use rsvg-convert and do it without going through shellbox - I guess for performance reasons.

I'm not 100% sure how to proceed here - it should just work if we add rsvg-convert to the container, as it uses proc_open so it doesn't try to contain the process in any way.

So, in order to get this working, we would need to install rsvg-convert in the base mediawiki image in production-images, and then use that in building our mw-on-k8s images.

@Joe Thanks!

If it's any concellation, these are not user-generated SVGs. They're only ~1KB SVGs that are code-reviewed, checked-in, on-disk as part of the deployed software.

@Joe Thanks!

If it's any concellation, these are not user-generated SVGs. They're only ~1KB SVGs that are code-reviewed, checked-in, on-disk as part of the deployed software.

I fully realize this, else I would've advocated for using shellbox. Out of curiosity, why are we rasterizing these images live instead of pre-generating renderings at fixed sizes? It seems somewhat wasteful but I'm sure I'm missing some detail.

Change 920206 had a related patch set uploaded (by Effie Mouzeli; author: Effie Mouzeli):

[operations/docker-images/production-images@master] php-multiversion-base: add rsvg-convert

https://gerrit.wikimedia.org/r/920206

Change 920206 merged by Effie Mouzeli:

[operations/docker-images/production-images@master] php-multiversion-base: add rsvg-convert

https://gerrit.wikimedia.org/r/920206

Change 920210 had a related patch set uploaded (by Effie Mouzeli; author: Effie Mouzeli):

[operations/docker-images/production-images@master] php-multiversion-base: update readme

https://gerrit.wikimedia.org/r/920210

Change 920210 merged by Effie Mouzeli:

[operations/docker-images/production-images@master] php-multiversion-base: update readme

https://gerrit.wikimedia.org/r/920210

Change 920257 had a related patch set uploaded (by Effie Mouzeli; author: Effie Mouzeli):

[operations/docker-images/production-images@master] php-multiversion-base: add librsvg2-bin

https://gerrit.wikimedia.org/r/920257

Change 920257 merged by Effie Mouzeli:

[operations/docker-images/production-images@master] php-multiversion-base: add librsvg2-bin

https://gerrit.wikimedia.org/r/920257

Added librsvg2-bin to php-multiversion-base

[…], these are […] ~1KB SVGs that are code-reviewed, checked-in, on-disk as part of the deployed software.

[…]. Out of curiosity, why are we rasterizing these images live instead of pre-generating renderings at fixed sizes? […]

In a nut shell, because we're not rendering the SVG as-is. The SVG is effectively a template that we make a slight variation of, and then we render that variant to PNG.

Each variant has a different color. We don't know the color until runtime, as it is color is determined by skin configuration, which is thus controlled by each skin, and and maintained separately from MediaWiki core where the icons themselves are maintained.

Beyond that, our Principles guide us to, if a reasonably simple and secure way exists to improve usability for developers without sacrificing end-user performance, that we do so. This leads us to largely have an invisible build step, where stuff just works :)

AFAICT this is now resolved.