There is an ongoing effort to rewrite our production thumbnailing infrastructure around Thumbor servers. The objective is to ultimately stop storing thumbnails in Swift, to remove the need to run mediawiki on image scalers and to generally have a more maintainable platform.
At this stage the new Thumbor-based stack is being developed on Vagrant. The working proof-of-concept developed that way will serve as the basis of the upcoming RfC to deploy this solution to production in stages.
Currently Thumbor is only configured to handle JPG and PNG files. Support for other file formats will follow, meanwhile those other formats will still rely on the existing thumbnailing infrastructure.
Thumbor is configured to keep a copy of original images in memcache for a short period of time. This is to cater for burst requests of several thumbnails of the same file, which happens during normal operations at upload time, when we pre-render the most popular thumbnail sizes.
Thumbor stores thumbnails on disk. This is only useful for disaster scenarios where Varnish would fail partly or fully. The plan to avoid the disk getting full is to delete thumbnails randomly when disk usage goes above a certain threshold. The randomness of the deletion is due to Thumbor having no way to know the traffic patterns of thumbnails when Varnish is in front of it. Deleting by age would be counter-productive, as hot thumbnails in Varnish are more likely to get old on Thumbor servers.
Thumbor has a single purging endpoint, which deletes a given original file and all its thumbnails from the Thumbor server. In situations of deletions (eg. copyvios), one should make sure that the original file is deleted in Swift first. The order of deletion/purging should be swift -> thumbor -> varnish backends -> varnish frontends.