These days, Bouncer's main purpose is download counting. If we end up moving to S3 and _not_ using CDNs, Bouncer probably isn't going to work for us anymore. It requires filenames that are well known and consistent, and we're not going to have that with S3. If we decide to go down this path, we should make sure that we're not unknowingly losing our download stats. IIRC, there has been some talk about continuing to use CDNs with S3 because they may be cheaper. If we do that, we should be able to continue using Bouncer as we do now and just remove FTP as backend. It's not clear to me how the CDNs would get configured to find the release data, but I'm sure that can be figured out.
I think we're always going to need CDNs to handle the level of traffic, but the set of CDNs may change over time. Of course we could point directly at the CDN if we teach everything (ie balrog blobs, www.mozilla.org etc) about the paths they need to know - bouncer is a useful abstraction in that sense. The first step in switching to S3, in my head at least, is simply to have a bucket where we put releases, (and another for candidates). Then we can change the CDN origin to http://<s3 domain>/mozilla-releases/ and the existing paths of firefox/releases/<version>/blah/blah still work. Until I wrote this I imagined we'd have one bucket per app, but that would require multiple CDN configurations. S3 ACLs should let us control access by app in a consolidated bucket though.
Ah, my s3-newb brain didn't realize that we could define file paths on s3 - I thought we could only point at random hashes. This seems much easier now.
It sounds like this is going to end up being a non-issue. We'll definitely continue to use Bouncer, and probably CDNs as well. Putting stuff in release buckets is likely going to be handled elsewhere. I'll leave this bug open for now, but there's probably nothing to do here.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.