On Fri, Oct 7, 2022 at 1:40 AM Taavi Väänänen <hi(a)taavi.wtf> wrote:
On 10/7/22 03:43, Bryan Davis wrote:
For the fonts themselves, should we:
* Revert the change and tell svgtranslate to move back to the grid?
* Propagate the change outward by making the same/similar change to
all php images?
* Propagate the change outward by making the same/similar change to
all base images?
* Let it be.
First of all: I don't see anything specific on the PHP images, so if
we're going to keep the fonts, I think we should move them to the base
images.
This would be the "Propagate the change outward by making the
same/similar change to all base images" option from my list I think?
I'm ok with moving the fonts to the base images. As legoktm pointed
out in
https://gerrit.wikimedia.org/r/c/operations/docker-images/toollabs-images/+…
the PHP images have librsvg2-bin added which is a semi-obvious use
case for more fonts, but there are certainly other ways that fonts
might be useful.
For the bigger
picture of breaking our long held stance on "bloat", I
would like to hear suggestions from y'all.
My concern with the current form of Docker images has been for a while
that once something has been added to it, it's pretty much impossible to
remove that without breaking previously-working volunteer maintained
projects (for example: Python2/3 used by webservice-runner).
This is inherent not only in the Docker images, but also in the Puppet
manifests that we use and to a lesser but real extent the operating
systems and versions that we use. Anything and everything that ends up
on a bastion or exec node will be treated as a feature by someone. I
don't say this to imply that you are wrong, just that this is a much
larger issue than Docker images.
So I'd propose to revert the change while we work
out what to do with it
on the medium/long term.
This would be the "Revert the change and tell svgtranslate to move
back to the grid" option from my initial list of next steps. I'm ok
with this too. The hopefully medium term solution really should be
support for custom containers for tools which is currently hoped to be
provided by a buildpack system.
I do think that fonts needed for rendering images
falls into the
category of "specialty features for a small number of use cases" that
you mention in your cloud@ post. Long-term this feels like a great use
case of a build pack based image, but as I mentioned already I don't
have up to date information on the current vision and roadmap for that
project.
I agree that TTF font support is a niche concern among tools primarily
affecting tools that somehow generate images. It is also a thing that
buildpacks should help provide a more general solution for. I don't
know a whole lot more than Tavvi does about how soon buildpacks will
be ready for actual users to work with. I do know that David, Slavina,
and Raymond are all working on that project, but I haven't seen any
concrete timeline projections.
Offered not as an excuse, but as data, the uncertainty about when and
how buildpacks will be available to Toolforge users was part of my
internal debate that led to reversing my past bloat blocks on this
same feature. I know that there is a strong push to get tools off of
the job grid. I assumed that this push was at least partially
responsible for the CommTech folks having moved svgtranslate from the
grid to kubernetes again after trying previously in 2019. It felt
shitty to tell them that they had to go back again because fonts would
not be allowed until they could add them for themselves with a
buildpack... someday. In hindsight however I should have given this as
the answer.
Bryan
--
Bryan Davis Technical Engagement Wikimedia Foundation
Principal Software Engineer Boise, ID USA
[[m:User:BDavis_(WMF)]] irc: bd808