Changing priority, because the code mentioned is not in production yet.

@Gehel and @Pchelolo any thoughts?

@eranroz do you have a link to the abandoned/WIP patch?

Thanks, @sbassett!

@Mrjohncummings, I am not sure yet how I can help you with this case, I read the long discussion at T154071: Allow non-CC0 licensed data for datasets and I am now trying to understand the technical aspects of this issue. I need to point out that we are not planning active development on JsonConfig, but will be available to support any volunteer work, as mentioned in T154071#4323571.

This problem is not happening anymore in maps100[1-4] (see log below) with the new stretch environment but codfw cluster is not ready yet. I'm reopening and moving it to the "to deploy" column on the kanban because it is fixed and just need the migration/deployment to finish in codfw.

$ tail -f /var/log/waterlines/import.log-20190202                                                         
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
COMMIT
ANALYZE
Fri Feb  1 09:15:48 UTC 2019 - waterlines import completed

@Pikne it seems that it is more related to the OSM replication system but I can't replicate this specific object that you suggested (see image below), I will start invetigating this problem and see if that is really an issue with that.

@daniel the team responsible for Maps maintenance is the Reading Infrastructure. I am tagging it so we can evaluate this task.

@bearND is the pagelib inline script that you refer is added by addPageLibJs()[1]?

In T211881#4878426, @akosiaris wrote:

@akosiaris, the logic in <An unorthodox architecture of the API of the service> is fundamentally flawed. The client only knows about the graph's hash because MediaWiki parser knew the exact graph data, calculated a hash, and stored that data under that hash in a key-value store (page_props), and included that hash in the HTML. Also, this structure is identical to the way maps function -- map data is calculated by the parser, stored in the key-value page_props with the hash as the key, and kartotherian service does exactly the same steps as graphoid - pulls that data out of page_props to render a static image (so that Leaflet libs are not downloaded until the user interacts with the map). In short - the ONLY component that knows what user wants to draw is MediaWiki parser.

[...]
By the way, page_props.pp_value field is a blob and hence bound to 65k. That does not sound like enough space to store the representation. In fact from what I see at T184128 this has already happened?

@Gehel, @Jhernandez and @Mholloway the instance maps1004 is ready to go and the updated report is available here https://www.mediawiki.org/wiki/Wikimedia_Maps/Tile_generation_report

@Bawolff the CSP affects Wikivoyage as described above, I would like to ask: how do you think we should do deal with that?

Tested the above patch and the output is the following:

@Jc86035 I will take a look into that, if you find something else please let us know. Thanks!

Last week I tested Kartotherian/Tilerator with a proper environment building mapnik pre-release master branch and node 10. The Dockerfile I created is here. I wrote a report and what I think that should be the strategy for the node 10 upgrade in another task at T213077: Migrate Kartotherian/Tilerator to Node 10. I would say that this "investigation task" is ready for sign off.

@Pikne thanks for working on top of that, I will take a look! Were you able to test it? I am asking out of curiosity because I am working on a Docker-compose environment for Kartotherian.

CSP affects Kartographer on Wikivoyage on the multi-layer selection feature. The layers that get Report Only error with URL examples are:

• Mapnik -> https://a.tile.openstreetmap.org/z/x/y.png
• Relief map -> https://a.tile.thunderforest.com/landscape/z/x/y.png?apikey=ca8e8a8e3f9a44c19a8edcf8fb5f90c4
• Traffic line network -> http://www.openptmap.org/tiles/z/x/y.png
• Boundaries -> http://korona.geog.uni-heidelberg.de/tiles/adminb/x=111&y=48&z=7
• Hill shading -> http://c.tiles.wmflabs.org/hillshading/z/x/y.png
• Cycling - > http://tile.waymarkedtrails.org/cycling/z/x/y.png
• Hiking -> http://tile.waymarkedtrails.org/hiking/z/x/y.png
• Nearby Articles -> https://tools.wmflabs.org/wikivoyage/w/data/en-articles.js

@LGoto I will triage it as normal but Michael and I will revisit it tomorrow on Maps grooming. Thanks for noticing!

In T211885#4828298, @zeljkofilipin wrote:

Is this resolved?

In T211419#4828174, @MoritzMuehlenhoff wrote:

This might have been truncated by the size of your terminal window. If you instead run e.g. "COLUMNS=200 dpkg -l nodejs" it should display the whole width. But if your tests on deployment-maps03 were fine, we should be good to go.

Both machines still show the header:

$ dpkg -l nodejs
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend                                                        
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)

Not sure if something happened. I checked the version two days ago and it was 6.11.0~dfsg-1+wmf5* for both wmflabs instances. Now I get the following outputs.