Heya,
I asked this on IRC but didn't get any replies so I'm following it up this
way.
I have a question about the newer metrics REST v1 API: is there a way to
specify how many top articles to pull from
https://wikimedia.org/api/rest_v1/#!/Pageviews_data/get_metrics_pageviews_t…
or is 1k hardcoded? Old metrics data was available that had the most viewed
pages but that disappeared with the change to the new API.
The reason I ask is because we (https://endlessos.com) are trying to
rebuild our stale encyclopedia apps for offline usage but are space-limited
and would only like to include the most likely pages that would be looked
at that can fit within a size envelope that varies with the device in
question (up to 100k article limit probably) but the new API doesn't
provide us with the tools to figure out the rankings cleanly (other than
rate-limiting on our side and checking every single article's metric
endpoint for counts).
So the main question is: do we have a way to get this data out with the
current API? If this data is not available, can the "metrics/pageviews/top"
API be augmented to maybe have a `skip` and/or `limit` params like other
similar services that have this type of filtering?
Thanks,
..........................................................................
Srdjan Grubor | +1.314.540.8328 | Endless <http://endlessm.com/>
FYI
---------- Forwarded message ----------
From: Daniel Zahn <dzahn(a)wikimedia.org>
Date: 27 March 2018 at 19:24
Subject: [Ops] new deployment server (tin -> deploy)
To: Operations Engineers <ops(a)lists.wikimedia.org>
Hi,
good old tin.eqiad.wmnet was out of warranty and running jessie,
so as part of our hardware refresh goal it had to be replaced by something
new.
We now have deploy1001.eqiad.wmnet and it's running on stretch with PHP7
and we just switched deployment servers and Mukunda is running the first
deploy from it as we speak.
<+logmsgbot> !log twentyafterfour@deploy1001 Started scap: Deploy
1.31.0-wmf.27 to test wikis
Here are the related puppet changes that switched it and added stretch
support:
https://gerrit.wikimedia.org/r/#/q/project:operations/
puppet+branch:production+topic:deploy1001
Additionally mwscript needed a way to detect php5 or php7, for that see:
https://gerrit.wikimedia.org/r/#/c/422348/
There are also more details on today's SAL and on:
https://phabricator.wikimedia.org/T175288
tin has not been killed yet and for now remains a scap master, just in case.
--
Daniel Zahn <dzahn(a)wikimedia.org>
Operations Engineer
_______________________________________________
Ops mailing list
Ops(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ops
On 06/03/2018 19:44, Marko Obrovac wrote:
> Hello,
>
> Today during the scheduled deploy window of moving JobQueue jobs from
> the Redis-based infrastructure to the new EventBus-based one, a
> combination of PEBKAC and Gerrit trying to be smart caused an accidental
> merge of the mw core's master branch into wmf.23. Luckily, the mistake
> was spotted before the wmf.23 branch got updated on tin, so the blast
> radius was limited to delaying the Euro-SWAT window by 30 minutes~[1].
> Big thanks to Antoine and Giuseppe for their help in discovering and
> resolving the issues.
>
> You can read the full incident report here~[2]. The TL;DR is that
> currently MW core repository is configured in such a way so as to allow
> Gerrit to do implicit (and silent!) merges, even for cherry-picked
> change-sets, which is something we might want to change in the near future.
>
> Cheers,
> Marko
>
> [1] Thanks, James F, for patiently waiting on the resolution!
> [2] https://wikitech.wikimedia.org/wiki/Incident_documentation/20180306-MasterM…
>
> Marko Obrovac, PhD
> Senior Services Engineer
> Wikimedia Foundation
Hello,
That Gerrit feature has been disabled by default for all repositories by
setting receive.rejectImplicitMerges = true in All-Projects.
https://gerrit.wikimedia.org/r/#/c/416704/
Implicit merging of a branch into another might be helpful sometime, but
most probably all typical use cases would be due to a mistake and could
lead to a catastrophe. I blame Gerrit default behavior on that one :]
I would like to thanks Marko and Petr to have followed the deployment guide:
* always check current workspace and remote before rebasing:
git remote update
git log HEAD..HEAD@{u}
* halt immediately and ring the bell in case of doubt. Surely have ~90
unwanted commits was a red alarm.
Thank you!
--
Antoine Musso