On Fri, Oct 7, 2022 at 1:40 AM Taavi Väänänen hi@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