@Halfak Added a subtask.
Deployed to production, resolving.
I'm not sure whether it makes sense to add this to the REST API. It wouldn't benefit from caching at all, and although we support logged-in calls, the actual authorization is based on the mediawiki API, so calling action API for this data would most likely be more efficient then wrapping it to the REST API
Fri, Apr 21
Created a subtask for that work @Jdforrester-WMF will implement next week.
@Jdforrester-WMF Hm... Good idea. Gateway timeout might be a more appropriate error here I guess. What do you think?
Parsoid is dying on this page with an exception from T163330 so should get resolved after the next Parsoid deploy
Thu, Apr 20
The patch was merged, to be deployed on Monday
Wed, Apr 19
To enable topic deletion we need to put delete.topic.enable=true to the kafka server.properties and restart instances.
Tue, Apr 18
Actually, that has been already done and announced with a blog post. Resolving.
All right @Ottomata, I'll try to remember python which I didn't use in like 5 years, let's see where it gets us :)
@Ottomata would you have any spare cycles to work on this or to guide me a bit through the event logging code to see how to do that? I'm slowly progressing on the general task and this seems to be a logical next preparation step..
I guess the patch was deployed and I haven't seen these errors in the RB logs for a while, so the issue can be closed.
Thu, Apr 13
Created a PR for RESTBase to allow 5 minutes of client-side caching: https://github.com/wikimedia/restbase/pull/795
After moving to scap3 this ticket is obsolete, resolving.
I guess after move to scap3 this ticket is obsolete, so I'm closing it as resolved. If disagree please reopen.
After switching to scap3 this is not relevant any more
@Pchelolo I don't know if you had in mind some programmatic means of looking at these, but I sampled a number of these at random and found them to have less VE usage than commons (or none at all).
At that point - yes, just tried to rerun it - same thing. I have vagrant settings nfs_shares off because of the T158617 , otherwise it's a standard vagrant setup
Wed, Apr 12
The prefacing rule is now updating ORES in both datacenters. Although there's still room for improvement, this issue can be resolved now.
Here's the list of wikis that will be affected by the truncate:
Tue, Apr 11
After a bit of hassle the newest version of the service has been deployed.
Although the patch was merged, the situation didn't change - the exact same log is produced on server restart. This blocks deployment of the new version T160764 because, although for the old version the error was there, it didn't prevent the service from starting up. The new version just hangs after the AssertionError and doesn't accept connections. In beta cluster though this doesn't happen.
The same thing has just happened when I've tried to update the service to a newer version (see T160764). Will put the patch for puppet SWAT and attempt to deploy after it's merged.
Fri, Apr 7
@Mvolz I've just tested in my local Vagrant and both works for me. Do you have the latest RESTBase code there?
Thu, Apr 6
Out of your list there's a couple of candidates that I immediately agree with and I propose to start with them and see where that brings us:
@Jdlrobson The page-restrictions-change event is there, so now you can do whatever you want with it. To subscribe to it just add the topic to the list in the EventSource
And the event is life! Resolving.
Wed, Apr 5
Tue, Apr 4
Awesome, that gives us enough time before the DC switchover. Perfect timing :)
Any progress on this? We need to make some changes to ChangeProp ORES config to prepare for DC switchover and wanted to do it simultaneously with using the new endpoint.
Mon, Apr 3
Since there's been no reports of any issues, we will be moving on this tomorrow, April 04.
@Nuria Yes, I'm using the latest vagrant puppet.
Fri, Mar 31
The connection timeout is not an issue here, it fails even without it.
Thu, Mar 30
I think the technical requirements are actually the same, since we aren't really looking for a binary blacklist anyway. Where do you see differences?
This is assuming that we don't want to rate limit successful jobs. Those can still use significant resources. Many of the wide row issues were caused by pages that rendered just fine, but were re-rendered over & over.
Update requirements are basically one per executed changeprop task.
Deployed, verified, resolving.
Wed, Mar 29
Depoyed, enabled, verified to be working.
@Joe You've told that we would be able to use an existing Redis cluster for reduplication in ChangeProp, but it seems we've found a more pressing issue that would also benefit from adding a storage. To sum up the above, our uses for Redis are:
Your problem is on us. At some point we've made CORS optional and moved it to a filter that has to be explicitly configured. See this section of the config. Also, but default all outgoing HTTP requests are prohibited, so you need to add this section to the config if you don't have it yet.
Tue, Mar 28
After upgrading the node-rdkafka to a newer version and using a different approach to delivery report memory doesn't leak any more, so the issue was automagically resolved.
Merged and deployed!
The new version was deployed to the deployment-prep and results are available under https://en.wikipedia.beta.wmflabs.org/api/rest_v1/#!/Page_content/get_page_pdf_title
+1 to @Ottomata
Mar 24 2017
Hm... I think event without code generation we still need to disallow some JSON schema features, for example regexes since they could be used for a DOS attack.