Data uploaded.

@Dominicbm thanks for submitting this. I'm having issues reproducing your problem - can you reliably reproduce it on your end and post a step by step instruction here?

Mitigated with - https://gerrit.wikimedia.org/r/c/operations/puppet/+/745901

Based on https://xeraa.net/blog/2021_mitigate-log4j2-log4shell-elasticsearch/#what-does-that-mean-for-elasticsearch , RCE type vulnerability doesn't apply to Elasticsearch thanks to use of SecurityManager, but since our instances are using JRE8, there are some vulnerabilities still, that can be fixed by using mentioned system property.

We seem to be missing the docs on MoreLikeThis. It would be nice to get MediaSearch API documentation as well, if available - @Cparle is it?

Putting in waiting to mark the need of repeating the process in two weeks.

Based on nginx logs (which are kept over two weeks) - https://drive.google.com/drive/u/0/folders/1ojrcehL7Bz0Cc4wKgdtD8CccruNK8lyh

Sorry all for the confusion my typo caused, different name for that magnitude in my native language is confusing me my whole life :).

More information provided on wikidata-tech,wikidata mailing lists - https://lists.wikimedia.org/hyperkitty/list/wikidata-tech@lists.wikimedia.org/thread/O5UWOENIEDA2GJSDBL3MEBBFH7ZPXFNY/

Here's a proposal for an SLO dashboard, that can use historical data to provide insight into the past performance: https://grafana-rw.wikimedia.org/d/yCBd7Tdnk/wdqs-lag-slo

Thanks for bringing this up, we haven't explain that part very well yet.

@BPirkle when this code was written, there was a bug (now fixed) that prevented us from using OAuth2. Now we could, but since we consider this a temporary measure (with API gateway being a more solid one in the future, as mentioned here T290300), we probably leave this as it is right now.

• Does this method returns anything?

No, there's no need - if there are issues, there will be exceptions raised, otherwise it's ok.

Configuration is added in this patch - https://gerrit.wikimedia.org/r/c/operations/puppet/+/721857

Patch is available here https://gerrit.wikimedia.org/r/c/operations/software/spicerack/+/723214

@LucasWerkmeister current WCQS-beta behaviour is a bug - sparql endpoint should be authenticated as well, not only UI (we created a ticket for that - T290889) . Production WCQS will start with the authentication already in place.

We should figure out who is the holder of the auth consumer - we probably should have a service account for mediawiki

@Lydia_Pintscher, @LucasWerkmeister, just to confirm(or the opposite) what we discussed in email thread - only thing required here is the doc update?
@Cparle - this is probably of interest to SD team as well.

Plan right now assumes that WCQS API will be provided via https://api.wikimedia.org/ - technical feasibility is still to be assessed. This will allow us to provide an OAuth 2.0 flow and standardised experience similar to other future wikimedia APIs.

The most important parameter to streaming updater is related to storage - we have a huge surplus of computing resources in WDQS streaming updater, since edit rate is much lower in SDoC, there is no risk when it comes to throughput.