We could use a Swift installation to support the projects in the labs infrastructure. I have identified at least a couple use case: Beta cluster and CI.
Beta cluster
=========
The first use case that has been pending for a while: it is to align #beta-cluster to production {T64835} for hosting files/images.
IIRC we currently use an emulation of the media server service that pre date the deployment of Swift. It is running unpuppetized on `deployment-upload` with Nginx and a stalled MediaWiki code base (thumbs.php and others).
Related bugs:
* {T64835}
** {T84950}
*** {T71757} (has some overview about the current setup}
Continuous integration
=================
There are growing needs for CI to publish and store build artifacts such as logs, tarballs, generated documentation, code coverage reports.
The CI tracking bug is {T101545}, and blocks a few use cases:
{T72945}
{T64633}
{T101542}
{T101543}
{T101544}
Imagine sending a patch to Gerrit and having Zuul report back with the URL to the coverage report and the generated documentation. That will surely help reviewers. Such content being temporarily, it would need to be discarded after some days.
After a merge occur, we publish some documentation to https://doc.wikimedia.org/ and a few coverage reports at https://integration.wikimedia.org/cover/ . That is currently done by having jobs rsync to a specific labs instance and then rsync from gallium (which hosts doc/integration.wikimedia.org). Documented at: https://www.mediawiki.org/wiki/Continuous_integration/Documentation_generation . Those would need to be stored indefinitely (in most cases).
Others
=====
I believe other labs projects such as `tools-labs` could use a Swift object storage as well that would expose its material under a `wmfusercontent.org` URL automatically. For example the Meetbot reports http://tools.wmflabs.org/meetbot/ .