Closed Bug 1082208 Opened 11 years ago Closed 10 years ago

Update Snippets Site Admin to allow users to upload assets to the snippets CDN

Categories

(Snippets :: Service, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ckprice, Assigned: giorgos)

References

Details

Goal: Create an interface in the Snippets Site Admin which will allow administrators to upload assets onto the snippets CDN (snippet CDN created in bug 1058620). Interface Details: The interface will be a simple "Upload file..." interface linked to from the main menu. Once the file has been uploaded, the interface will respond with a corresponding CDN URL. History: Upcoming snippets will require animation assets which will exceed the 200KB limit on the snippet service (current estimates are 1-2MB). The solution is to host the assets on a stable CDN, then call the assets from within the snippet. Launch date for the 10th anniversary snippet is 11/10/2014 Risks: :jakem - Will the snippet CDN be able to handle the increase in bandwidth? Are there other IT concerns we should take into consideration with this approach?
Flags: needinfo?(nmaul)
I wouldn't worry about CDN bandwidth for Snippets. In the grand scheme of things, Mozilla as a whole is a comparatively small fish (bandwidth-wise, to a CDN vendor). Additionally, Snippets (even with big snippets) seems likely to be a small part of our overall CDN bandwidth which is historically dominated by Firefox Desktop updates. I don't have any IT-related concerns for this... the ability to use bigger snippets and to update faster were the primary drivers to setting up the CDN.
Flags: needinfo?(nmaul)
One thing to keep in mind is that we want to be able to update a file without changing the public URL, in case we need to update an image without having to change the snippet being sent out. So uploaded files have to have some filename that doesn't change if the file does, and should be able to overwrite the old version. Maybe have a field for choosing the filename during upload?
Assignee: nobody → giorgos
That's problematic for caching, depending on the TTL. If we can simply wait it out that's the easiest. If we have to flush sooner, we'll want to come up with some way for you to do the flush from the app.
I think it'll be fine to wait it out. If the change is just on the image side, a 15 minute timeout is acceptable. If it's to both the image and the snippet code, we should be using a different filename since the old snippet code will be out for at least 24 hours anyway. I don't think there's a case where we need to force a flush.
Status: NEW → ASSIGNED
OS: Mac OS X → All
Hardware: x86 → All
(In reply to Jake Maul [:jakem] from comment #1) > I wouldn't worry about CDN bandwidth for Snippets. In the grand scheme of > things, Mozilla as a whole is a comparatively small fish (bandwidth-wise, to > a CDN vendor). Additionally, Snippets (even with big snippets) seems likely > to be a small part of our overall CDN bandwidth which is historically > dominated by Firefox Desktop updates. > > I don't have any IT-related concerns for this... the ability to use bigger > snippets and to update faster were the primary drivers to setting up the CDN. Hi :jakem, we are getting closer to deploying the updated Fx10 Gift snippet (Nov 10) which will be linking to the snippet CDN. Initial explorations have shown that we could be requesting assets of 2.5-3.5 MB. You said that bandwidth should be okay, but I just wanted to loop you in on the timing in case you needed to prepare anything. Also, do you have an approximate download/upload speeds we can expect? We are trying to get an idea of how long some of the assets would download on less-than-ideal connections. Thanks!
Flags: needinfo?(nmaul)
Download speed will depend almost entirely on the client's location and connection. It's hosted on Edgecast, so speed should be good anywhere they're good... especially North America and Europe, but also parts of APAC and South America. It'll be slower in other places, but those also tend to be the places where client connections are slow too (very fragmented peering) so there's usually not much we can do about it anyway. Timing doesn't matter to me.
Flags: needinfo?(nmaul)
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.