1020033 - CDN request: hosted distribution files

Status: RESOLVED FIXED

(Infrastructure & Operations Graveyard :: WebOps: Other, task)

Description

[Richard Newman [:rnewman]]

tl;dr: can we get a CDN for partner distributions?


In Bug 1013024, we're working to allow Firefox for Android to download distribution zips (containing default bookmarks, search engines, and so on) from the network during first run.

This will allow us to deliver branded experiences for partners based on referrer codes, without having to bake partner distributions into everyone's copy of Firefox in advance.

Of course, this means we need a place to put these small bundles of data.

Tentative requirements:

* Relatively high availability (not yet quantified, but SLA will naturally play into partner negotiations). Partners have an expectation that a referral will yield a branded experience, and that depends on the availability of the distro file.

* Geographic coverage. So far we have two non-NA regions on the table.

* Basic access statistics.

* Low frequency of additions and updates, so no need for heavy tooling.

* Unknown reach, but each user should fetch a distro only once.

* Unclear yet whether this requires HTTPS.


Happy to answer any questions. What else do we need to get this moving?

Comment 1

[Chris Turra [:cturra]]

we did something similar to this over in bug 981801. basically, we used amazon s3 as a storage and origin location and fronted all of that with edgecast. seems to have worked out okay, tho, i'm not entirely sure how we can deliver your request for access statistics if this is relying heavily on cache hits. 

:rnewman - can you review that bug and see if it aligns with what you're asking for?

Comment 2

[Richard Newman [:rnewman]]

As far as I can see, that'll work; I see from Bug 981801 Comment 11 that you got SSL to work, so we still have that option available to us, which is great. Dumping stuff in an S3 bucket is fine for our upload needs.

Does the EdgeCast caching layer generate access logs? I don't mind having to do manual work; I just want to have a better answer than diffing FHR snapshots when a partner wants to get daily clickthrough data.

(We might be able to pull this data out of the Play store; if that's the case, then no stats needed.)

Comment 3

[Richard Newman [:rnewman]]

Mark, do you know if Play reports stats for referrer clickthroughs, or do they expect you to do that with Google Analytics in your app?

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Richard Newman [:rnewman] from comment #3)
> Mark, do you know if Play reports stats for referrer clickthroughs, or do
> they expect you to do that with Google Analytics in your app?

Distributions are sent back to Mozilla using the blocklist ping, so we should have decent coverage of what distributions are active in the field and how long those users are staying active, since the blocklist ping will provide "longitudinal" data, not just a "once and done" ping.

Comment 5

[Richard Newman [:rnewman]]

I don't have access to that Kanbanize site, so: can we get a quick status update, please?

Comment 6

[Chris Turra [:cturra]]

(In reply to Richard Newman [:rnewman] from comment #5)
> I don't have access to that Kanbanize site, so: can we get a quick status
> update, please?

:rnewman - this bug is still in our backlog lane waiting on other tasks to wrap up to free up resources for your request. is there an explicit deadline this work needs to be complete by? this would help us prioritize the task against the other requests in our backlog queue.

Comment 7

[Richard Newman [:rnewman]]

Razor-edge hard scramble deadline is 4 weeks before 33 merges to Beta, to allow for enough QA. That's the start of August. I'd prefer not to do that scrambling, of course!

My ideal deadline is 4 weeks before 33 merges to Aurora, so that we don't have to fix stuff on Aurora or Beta. That's some time next week.

If that deadline is impossible, an interim work item would be having the final hostname pointing somewhere other than the prod CDN; so long as it gives us a 200 for a zip file, we'd be freed up to land final code and do QA.

For context: this bug, sec review, and review of the last bug (Bug 1013024) are the only work items remaining for the feature.

Let me know if you need any more details, and thanks!

Comment 8

[Chris Turra [:cturra]]

thnx for the detailed response :rnewman. i'm not sure we can commit to this being complete next week, but will bring it up in our daily stand up tomorrow. looking at our current wip (work in progress) i suspect we should be able to prioritize this in the queue for the first week of july. do you have any objections to that timeline?

Comment 9

[Richard Newman [:rnewman]]

(In reply to Chris Turra [:cturra] from comment #8)
> the first week of july. do you
> have any objections to that timeline?

I think we can make that work. Keep me posted!

Comment 10

[Chris Turra [:cturra]]

:rnewman - can you pls provide me with a list of users who will need to be able to upload content? each will need to have accounts created under out aws account.

Comment 11

[Richard Newman [:rnewman]]

(In reply to Chris Turra [:cturra] from comment #10)
> :rnewman - can you pls provide me with a list of users who will need to be
> able to upload content?

Let's start with me, mleibovic, mfinkle, and dria. I think that gives us enough flexibility without being unmanageable.

mfinkle, please chime in if you disagree.

Comment 12

[Chris Turra [:cturra]]

:rnewman - i have finished up a first pass on this, with only your user account so we can get some testing complete. you will find your credentials in your home directory on people (s3user.txt).

there is now an amazon s3 bucket in place to store the distro-download files, which i have fronted with edgecast cdn including ssl support. files uploaded to this datastore are accessible from:

  https://distro-download.cdn.mozilla.net


i have created a 'test' directory, which has public read permissions you can test uploads to. here is one that i did:

  https://distro-download.cdn.mozilla.net/test/dino-wallpaper.png


let me know how you make out.

Comment 13

[Richard Newman [:rnewman]]

That works for me, Chris, thanks; uploaded, set a+r, downloaded from a browser. Running a build now to do some testing from Fennec.

Comment 14

[Richard Newman [:rnewman]]

This is looking good, Chris.

Could we get an "android/1/" (or "android.1/") directory set for prod usage created alongside "test"? I don't seem to have permissions to do so.

Thanks!

Comment 15

[Mark Finkle (:mfinkle) (use needinfo?)]

"android/1/" has my vote

Comment 16

[Chris Turra [:cturra]]

android/1/ directories created in s3 bucket and their permissions have been set to public.

Comment 17

[Richard Newman [:rnewman]]

Perfect, thanks Chris! The quick turnaround is much appreciated.

I think we can close this bug out as soon as the other folks get their credentials.

Comment 18

[Chris Turra [:cturra]]

(In reply to Richard Newman [:rnewman] from comment #17)
> 
> I think we can close this bug out as soon as the other folks get their
> credentials.

sounds good! i have added accounts for: mgoodwin, mfinkle and dria as requested previously and added them to the same s3 bucket permissions group. each of them can find their amazon access in their home directory on people in a file called `s3user.txt`