Fri, Jun 22
Instead of dying it probably should just ignore the transformation.
Thu, Jun 21
The users in the deploy-service group can sudo service (start|stop|restart) * on the target nodes, so it essentially is a sudo request.
The only thing that pops to mind is varying by content version (Parsoid HTML v1.5 vs v1.6 for example), but for that to be a valid cache fragmention criterion we'd need to be able to convert between various formats.
Wed, Jun 20
@cscott when would Vary: accept be useful? Each end point has a distinct content type and clear usage. What would be the benefits of (generally) varying accept ? The less we fragment the cache the better, and things tend to get complicated if/when we introduce variations on the theme like gzip et al. I would be inclined to support only Vary: accept-language since this is the only header that we will realistically vary content for.
Tue, Jun 19
Mon, Jun 18
The patch above increases the rendering concurrency, whichwas too low for production purposes any way. It should resolve the immediate problem of the time outs. The actual reason for the timeouts is that service checker runs all the tests in parallel. Since there is a reasonable chance that two requests issued simultaneously end up on the same process.
Is the wiki readable by anonymous users? If it's not, then my answer still stands. If not, the siteinfo call might be failing because the link between RESTBase and MW is misconfigured. Namely, apiUriTemplate: http://wiki.MYDOMAIN.XX/api.php might need some tweaking. Is that URL reachable from the machine powering RESTBase?
LGTM, +1, let's do it! :)
The failure was due to a mismatch in Cassandra version. We were in the process of upgrading it, and that process has since been completed.
Wed, Jun 13
I added the hiera variable as per @Joe's suggestion and now all is good.
Because RESTBase will write a new meta record, we should also set the correct compression and compaction settings.