It looks like num_workers = 2 performed better if we consider failure vs RPS.

In T238830#5813108, @akosiaris wrote:

I just noticed that num_workers: ncpu in the chart. Sigh, this probably makes all CPU calculations wrong as it is impossible to size a pod that is dependent on the underlying hardware CPU wise. I 'll have to rerun those tests with values between 1,2,3

@akosiaris interesting! Thanks for testing it, maybe the better path for the benchmark would be to deploy proton alongside a mediawiki pod and change configuration to reflect the new URL for fetching wiki pages. What do you think? Is that worth to do?

In T238830#5810194, @akosiaris wrote:

@MSantos where were the tests run ? And how was the draft chart deployed? My reason for asking what that if this is tested locally and talks to wikipedia.org APIs the latency added over the internet could adversely affect the benchmark.

Highlighting service configuration in the gerrit patch just to make things easier:
https://gerrit.wikimedia.org/r/c/operations/deployment-charts/+/557090/2/charts/chromium-render/templates/config.yaml

In T242235#5790748, @Dbrant wrote:

Sure, here we go:
https://en.wikipedia.org/api/rest_v1/page/mobile-html/Earth
See the empty "References" and "Notes" sections.

The first tests indicate that the draft deployment chart doesn't have the proper configuration to run the service.

@Dbrant could you please provide some examples?

@Pchelolo and @Clarakosi, I wonder if this issue has anything to do with parsoid changes and if the recent restbase deploy could fix the language conversion problem.

We have to different problems going on here:

@kostajh thanks for pointing that out, our team is under-resourced for this quarter, so we might not have time to work on this. It would be good if Code-Health-Metrics could lead, no rush to have it done from our side though. I'm tagging Services as well to have more input from other teams who develop node services.

This should happen in every article that contains Wikitable template. Should be fixed on the template side.

@Dbrant are you still able to reproduce it?

@ssastry is that possibly a CI config? cc/ @hashar

@pmiazga any thoughts?

Also, these changes are supposed to be applied with mobile-html use, and it looks like you are seeing current Android implementation if you compare it with the images in the task description.

@schoenbaechler what version are you testing? I'm looking at PCS master branch and I see some differences from your evaluation on implementation.
At least issue 02 is not happening, see:

Well, I think it could be either way. My thought is to start k8s for proton with buster image, that way we just change deployment-charts once instead of twice.

@kostajh, before ore filling another phab task, I would like to ask: is it possible to enable the codehealth pipeline for our node services as well?

I would like to have a Documentation generated from JSDoc in these cases. Swagger UI won't fit in this case and updating pcs.md seems to not grasp all possible details of the interface as we would have on a generated doc.

cached-path-relative is also already fix in kartotherian/server and it's not a dependency in babel, see.

lodash vulnerability is fixed at least since https://gerrit.wikimedia.org/r/c/mediawiki/services/kartotherian/+/525816

In T216826#5717180, @Jdforrester-WMF wrote:

In T216826#5640424, @MSantos wrote:

@Mathew.onipe and @Jdforrester-WMF just FYI: I have tested kartotherian with debian buster and upstream mapnik library and it works just fine, which is a good thing since our backported mapnik library is outdated in comparison with debian stable (buster).

Wow, that's great. Is the next step writing and landing the changes to move directly to that?

Last time this error was logged was 2019-09-22T12:25:51. Please reopen if needed.

Not seeing this anymore, (since 10/30/2019). Please reopen if needed.

This change should happen in RESTBase . I have a WIP patch [1] to fix with some notes that I'm not being able to understand yet.

These labels seem to be handled by pagelib, see.

@JoeWalsh what is the expected content for data-description-source?

Related T142047: Audit and improve documentation for uses of innerHTML

The domino ones are dev dependencies: