Decide on & implement targets management for Rugged instance

To get an idea of what order of magnitude we're talking about - 650G is every packaged release of a Drupal project.

We’re only signing the zip files, since that’s what Composer uses. Zip files tend to be slightly larger than tgz, so let’s call it 400G.

We are only signing “current” releases, compatible with Drupal 8 and later. Let’s ignore that, since it’s not bad to over-estimate, and we have an addition next.

We are also signing composer metadata, which is 2 json files like https://packages.drupal.org/files/packages/7/p2/drupal/ctools.json per project.

So the space needed for targets is probably less than half a terabyte, for now.

Given that amount space used, we do want to solve this. Even if we eat the cost of the extra storage, operations like backup and restore, and other maintenance would take orders of magnitude longer.

A good, straightforward option is for something to delete files older than an hour on cron.

I expect that we're going to want to implement consistent snapshots at some point. See: § 6.2.1 Writing consistent snapshots for specifics. In that case, Rugged MUST keep multiple copies of each target file named: <HASH>.FILENAME.EXT. This would obviously increase the storage requirements significantly.

However, at the moment, I don't think that Rugged needs to keep processed targets. So we could have Rugged remove the target files.

I added the following feature request w/ Rugged: #132: Add option to delete target files once they're signed

I believe we have this resolved.

Automatically closed - issue fixed for 2 weeks with no activity.