The strategy looks good to me, I wonder if we can get this kind of check with just native JS and CSS easily without relying on 3rd party libraries

For posteriority, in a recent test we discovered that one hour's worth of OSM sync can generate 120000 single tiles for one single zoom, this can reach 5 times of this size if we consider re-generating zoom 10 to zoom 15, as we currently do.

1. /feed/featured/, /page/summary/, and /page/mobile-html support the Accept-Language header or have support provided by restbase
2. ...
3. Oddly, even though sr-el and sr-ec aren't BCP 47 compliant, they work. Other variants such as kk-latn and ike-latn are BCP 47 compliant but won't work when requesting /page/html endpoint. The languages have MediaWiki support though, as can be confirmed by the following examples:
   • https://translatewiki.net/w/i.php?title=Portal:Kk&uselang=kk-latn
   • https://translatewiki.net/w/i.php?title=Portal:Kk&uselang=kk-arab
   • https://translatewiki.net/w/i.php?title=Portal:Kk&uselang=kk-cyrl

@Dbrant and @Tsevener is this resolved or need more work to achieve the expected behavior?

@Mr_Patoot thanks for reporting this issue!

Kartographer already supports source configuration, this task will be more about setting it up in testwiki and assess if it's enough for our needs.

I think it's fine to leave at Product-Infrastructure-Team-Backlog so it's not orphaned.

I think it's fine to leave at Product-Infrastructure-Team-Backlog so it's not orphaned.

Documentation added at https://wikitech.wikimedia.org/wiki/Maps/OSM

The approach of the CLI looks good to me. We should now see how to backport the script to debian buster to use on the maps clusters.

A couple of notes around this ticket:

What @Mholloway described is a feasible effort we could work on, but I believe that this ticket needs to be discussed on a product management level. How do you want to approach that? cc/ @JTannerWMF and @MattCleinman

In T285668#7343992, @akosiaris wrote:

In T285668#7342496, @Bstorm wrote:

In T285668#7342314, @MSantos wrote:

I am late to the party, but tiles.wmflabs.org is not part of the official Maps infrastructure. I'm not sure how its infrastructure works and I've limited time to help you setup currently, maybe next quarter, but @Bstorm if you need to sync and know what we have available in terms of maps OSM tooling, please ping me for a chat.

We now use imposm3 to import data and it would be interesting to see this project do more fancy stuff, like using OpenMapTiles.

There's two pieces to all this here. We've got a maps project in cloud (which tiles.wmflabs.org is hosted on) that is run by volunteers and whoever knows how to make it work and a Postgres OSM database that is run by my team. That database consumes the same puppet stack as the production WMF ones as far as I know.

I don't think that's true anymore (albeit it's a recent development). While puppet abstracts it a bit so that the same defines and classes are used, maps in production now uses imposm3 while the one in WMCS still uses osm2pgsql in order to populate the OSM database.

@akosiaris is right, the puppet config is backwards compatible and to use imposm3 you need to enforce it, so it doesn't change tooling for tiles.wmflabs.org

I am late to the party, but tiles.wmflabs.org is not part of the official Maps infrastructure. I'm not sure how its infrastructure works and I've limited time to help you setup currently, maybe next quarter, but @Bstorm if you need to sync and know what we have available in terms of maps OSM tooling, please ping me for a chat.

We worked around it testing the needed capabilities locally exposing the beta cluster metrics endpoint. I'll decline this since it won't be needed.