Hello,
Today we have released v0.3.1 of service-template-node~[1]. While the
codebase itself bring only some minor improvements, it bumps
service-runner's version to 1.2.1 which brings many improvements over the
last version contained in service-template-node (0.3.8). Please update your
services to use the newest service template.
Cheers,
Marko
[1] https://github.com/wikimedia/service-template-node/tree/v0.3.1
--
Marko Obrovac, PhD
Senior Services Engineer
Wikimedia Foundation
We are planning to enable automatic redirect following in all REST API
[1] HTML entry points on April 25th. When responding to a request for
a redirected title [2], the response headers will contain:
Status: 302
Location: <path-to-redirect-target>
For most clients, this means that their HTTP client will automatically
follow redirects, simplifying common use cases. The few clients with a
need to retrieve the redirect page content itself have two options:
1) Disable following redirects in the client. For HTML and
data-parsoid entry points, the response still includes the HTML body &
regular response headers like the ETag.
2) Send a `?redirect=false` query string parameter. This option is
recommended for browsers, which lack control over redirect behavior
for historical security reasons.
If you do have a need to avoid following redirects, you can make these
changes before the feature is enabled. Internally, we have already
done so for VisualEditor and the Mobile Content Service. See also
https://phabricator.wikimedia.org/T118548 for background & related
discussion.
Let us know if you have any concerns or questions about this.
Thanks,
Gabriel Wicke for the Wikimedia Services Team
[1]: https://en.wikipedia.org/api/rest_v1/?doc (using en.wikipedia.org
as an example)
[2]: https://www.mediawiki.org/wiki/Help:Redirects
This is really great cross team work between apps and services.
Well done team.
On Tue, Apr 12, 2016 at 5:16 PM, Dmitry Brant <dbrant(a)wikimedia.org> wrote:
> Hi everyone,
>
> In the last few weeks, we've been rolling out the ability of our Android app
> to connect to the Mobile Content Service[0], built on RESTBase[1], for
> retrieving article content, and the rollout is now complete. Over the
> course of the next day or so, the app installed on your device should
> seamlessly switch over to using MCS instead of the MediaWiki (mobileview)
> API.[2]
>
> While this change won't affect your day-to-day browsing, it does mean that
> several additional features that were dependent on the content service will
> now become enabled in the app! These include:
>
> - Definitions of words from Wiktionary. Tap-and-hold any word in an article
> to highlight it, then tap the "Define" button to see a popup definition of
> the highlighted word. (Note: this is currently enabled only for English
> Wikipedia articles)
>
> - If an article has a recorded audio pronunciation of its title included in
> it, the app will display an "audio" button next to the article title. Tap
> the button to play back the pronunciation.
>
> - If an article has geo coordinates associated with it, the app will display
> a "pin" button below the article title. Tapping this button will open the
> default maps app on your device, and navigate to the coordinates of the
> article.
>
> Many thanks to the Services team for helping us reach this important
> milestone, and props to our own Bernd and Michael for their efforts to get
> this done. This will enable us to build future service-based features much
> more easily, and it's our hope that the content service will be adopted by
> many other consumers, not just the Android app.
>
>
> [0] https://rest.wikimedia.org/en.wikipedia.org/v1/?doc#/Mobile
> [1] https://www.mediawiki.org/wiki/RESTBase
> [2] This is done within the app itself, and does not require an update from
> the Play store.
>
> Cheers,
>
> --
> Dmitry Brant
> Senior Software Engineer / Product Owner (Android)
> Wikimedia Foundation
> https://www.mediawiki.org/wiki/Wikimedia_mobile_engineering
>
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
Awesome Dmitry! The iOS team is definitely looking forward to adopting the
Mobile Content Service in future versions.
Thanks to the Android team and the Services team for helping blaze this
trail.
On Tue, Apr 12, 2016 at 5:16 PM, Dmitry Brant <dbrant(a)wikimedia.org> wrote:
> Hi everyone,
>
> In the last few weeks, we've been rolling out the ability of our Android
> app to connect to the Mobile Content Service[0], built on RESTBase[1], for
> retrieving article content, and the rollout is now complete. Over the
> course of the next day or so, the app installed on your device should
> seamlessly switch over to using MCS instead of the MediaWiki (mobileview)
> API.[2]
>
> While this change won't affect your day-to-day browsing, it does mean that
> several additional features that were dependent on the content service will
> now become enabled in the app! These include:
>
> - *Definitions of words from Wiktionary*. Tap-and-hold any word in an
> article to highlight it, then tap the "Define" button to see a popup
> definition of the highlighted word. (Note: this is currently enabled only
> for English Wikipedia articles)
>
> - If an article has a recorded *audio pronunciation* of its title
> included in it, the app will display an "audio" button next to the article
> title. Tap the button to play back the pronunciation.
>
> - If an article has *geo coordinates* associated with it, the app will
> display a "pin" button below the article title. Tapping this button will
> open the default maps app on your device, and navigate to the coordinates
> of the article.
>
> Many thanks to the Services team for helping us reach this important
> milestone, and props to our own Bernd and Michael for their efforts to get
> this done. This will enable us to build future service-based features much
> more easily, and it's our hope that the content service will be adopted by
> many other consumers, not just the Android app.
>
>
> [0] https://rest.wikimedia.org/en.wikipedia.org/v1/?doc#/Mobile
> [1] https://www.mediawiki.org/wiki/RESTBase
> [2] This is done within the app itself, and does not require an update
> from the Play store.
>
> Cheers,
>
> --
> Dmitry Brant
> Senior Software Engineer / Product Owner (Android)
> Wikimedia Foundation
> https://www.mediawiki.org/wiki/Wikimedia_mobile_engineering
>
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
Hello,
The WMF’s technology department has for this quarter the goal of testing
and temporarily switching the main operational data centre from Eqiad
(located in Chicago) to Codfw (located in Dallas)~[1,2]. This includes both
back-end-processing as well as serving live traffic from it.
As a part of this effort, we are scheduling a switch-over for RESTBase and
its back-end services, including: Parsoid, the Mobile Content Service,
CXServer, Mathoid, Citoid, Apertium and Zotero~[3]. Technically, it will
not be a real switch-over per se, because we will keep all of those
services active in both DCs. However, external traffic will be directed to
the Dallas DC only.
=== When is it and what does it mean for me? ===
The switch-over test is planned for this Thursday, 2016-03-17. We have
allotted a three-hour window for this~[4]. There is nothing users should
do before or after the switch; it will be transparent for them. There are
two things users should note, though:
1) At the time of the switch-over, users might receive error responses for
a while (both 4xx and 5xx status codes). While we will test most of the
things ahead of time, we cannot test the actual traffic shifting, so small
bumps might be noticed.
2) After the switch to the Dallas DC, users will likely see their response
latencies slightly elevated. During the test, some requests might
experience a slightly larger latency. This will occur because all of the
services that will be responding to live requests still need to contact the
main MediaWiki cluster, which will remain in Eqiad (the other DC) until a
complete switch-over of the infrastructure is performed. However, given the
multiple levels of caching, the 40 ms of penalty to go cross-DC for an
uncached API request does not seem too taxing.
=== Wait, what about my service X running in WMF production? ===
If you are a service owner of one the aforementioned services, there are no
explicit actions you should take prior to, during or after the switch-over
test. This test could, however, affect your service depending on whether it
usually serves live traffic or is mostly operational during various
internal updates. MediaWiki and JobQueue processing will still be performed
in Eqiad, so in the latter case your service should not see a change in the
usage pattern. If, however, your service is mostly in charge of responding
to live requests coming through RESTBase, those will be handled by
instances in Codfw. However, as these services are full replicas of their
Eqiad counterparts and are stateless, no major breakage will happen.
Should you have any questions or concerns, don’t hesitate to contact us
here or on IRC (#wikimedia-services @ freenode).
Best,
Marko Obrovac, PhD
Senior Services Engineer
Wikimedia Foundation
[1]
https://www.mediawiki.org/wiki/Wikimedia_Engineering/2015-16_Q3_Goals#Techn…
[2] https://phabricator.wikimedia.org/project/profile/1723/
[3] https://phabricator.wikimedia.org/T127974
[4]
https://wikitech.wikimedia.org/wiki/Deployments#Thursday.2C.C2.A0March.C2.A…
Hello,
On 8 March 2016 at 02:49, Gabriel Wicke <gwicke(a)wikimedia.org> wrote:
> tl;dr: You are *very* likely not affected.
>
> We are planning two changes in the REST API:
>
> 1) Remove the experimental /page/html/ and /page/data-parsoid/
> listings [1][2]. Our metrics show that these are essentially unused.
> The same title listing remains available at /page/title/ [3].
>
> 2) Make the `tid` path parameter in the unstable
> /page/data-parsoid/{title}/{revision}/{tid} [4] end point mandatory.
> Data-parsoid is tied to a specific HTML render, and only requests with
> an explicit timeuuid from the corresponding HTML response are
> guaranteed to get the correct data-parsoid version.
>
These changes are scheduled to go live tomorrow around 10:00 UTC.
Cheers,
Marko
>
> If things go to plan, we will deploy these changes sometime next week.
>
> Thank you for your understanding,
>
> Gabriel Wicke for the Services team
>
> [1]:
> https://en.wikipedia.org/api/rest_v1/?doc#!/Page_content/get_page_html
> [2]:
> https://en.wikipedia.org/api/rest_v1/?doc#!/Page_content/get_page_data_pars…
> [3]:
> https://en.wikipedia.org/api/rest_v1/?doc#!/Page_content/get_page_title
> [4]:
> https://en.wikipedia.org/api/rest_v1/?doc#!/Page_content/get_page_data_pars…
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Marko Obrovac, PhD
Senior Services Engineer
Wikimedia Foundation
Hello,
We have updated the nodejs package version from 4.2.4 to 4.3.0 on the SCB
service cluster running in production. The services running there have been
restarted and tested. I have also taken the liberty to update the build
portion of the package.json's in the source repositories so that the
respective build systems create node dependencies compiled with the correct
version of the node binary. The affected services and their respective
patch-sets are:
- citoid: https://gerrit.wikimedia.org/r/#/c/274688/
- cxserver: https://gerrit.wikimedia.org/r/#/c/274685/
- graphoid: https://gerrit.wikimedia.org/r/#/c/274687/
- mathoid: https://gerrit.wikimedia.org/r/#/c/274684/
- mobileapps: https://gerrit.wikimedia.org/r/#/c/274689/
Note that because of these changes, the next time you build the deploy
repository it will take a while longer since the new version of Node.js
needs to be downloaded and configured in the service's container image. The
good news is that you don't have to do anything but wait a bit :)
Thanks to Moritz Mühlenhoff from Ops for making this happen!
Cheers,
Marko
--
Marko Obrovac, PhD
Senior Services Engineer
Wikimedia Foundation
Hi,
we are considering a policy for REST API end point result format
versioning and negotiation. The background and considerations are
spelled out in a task and mw.org page:
https://phabricator.wikimedia.org/T124365https://www.mediawiki.org/wiki/Talk:API_versioning
Based on the discussion so far, have come up with the following
candidate solution:
1) Clearly advise clients to explicitly request the expected mime type
with an Accept header. Support older mime types (with on-the-fly
transformations) until usage has fallen below a very low percentage,
with an explicit sunset announcement.
2) Always return the latest content type if no explicit Accept header
was specified.
We are interested in hearing your thoughts on this.
Once we have reached rough consensus on the way forward, we intend to
apply the newly minted policy to an evolution of the Parsoid HTML
format, which will move the data-mw attribute to a separate metadata
blob.
Gabriel Wicke
Hello,
Just wanted to let you know that I am flying back to Europe today and I am
not going to be working until next Thursday. In case of emergency, I should
be able to respond, though.
Have a nice week-end,
Marko
--
Marko Obrovac, PhD
Senior Services Engineer
Wikimedia Foundation