Closed Bug 434603 Opened 14 years ago Closed 12 years ago
SAMO should not pull images from AMO
We need to update SAMO's config so SITE_URL points to SAMO instead of AMO (which is the default). We'd be looking at adding this to site/app/config/config.php: define('SITE_URL', 'https://services.addons.mozilla.org'); Right now SAMO pulls images from AMO because SITE_URL is defaulting to AMO.
oremj - hold on for a sec, making sure this is all that is needed.
Summary: Update SAMO SITE_URL in config → SAMO should not pull images from AMO
even more than just images - the sites should be 100% self sufficient with no reliance between the two...hoping that's covered in this bug as well.
Easy enough. The old urls are a hangover from when they weren't separate.
Component: Server Operations: Web Content Push → API
Product: mozilla.org → addons.mozilla.org
Version: other → unspecified
not sure when 3.4.3 but this must happen before ff3 launch...what's the eta on 3.4.3?
Code freeze is Monday, will push next Thursday.
Fixed in r14442.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Hey Laura - is there a good testcase I can use to verify this? Something along the lines of changing the Firefox 3 in-client |extensions.getAddons.*| URLs to point to preview.*, and then using livehttpheaders to verify from where the images are being pulled?
Yep, look at e.g. https://services.addons.mozilla.org/en-US/firefox/api/1.1/addon/6534 compare to same page on preview (when preview is up again) The icon, thumbnail, and install urls should be on SAMO not on AMO.
Verified FIXED, comparing https://services.addons.mozilla.org/en-US/firefox/api/1.1/addon/6534 against https://preview.addons.mozilla.org/en-US/firefox/api/1.1/addon/6534. preview has: <icon> https://services.addons.mozilla.org/img/addon-icn.png </icon> <thumbnail> https://services.addons.mozilla.org/img/no-preview.png </thumbnail> <install hash="sha1:c2bf3313a1533a36dc94b4902e391addfa3290e3" os="Linux"> https://services.addons.mozilla.org/downloads/file/23772/_find_bar_-1.0-fx+tb-linux.xpi </install> Thanks for the testcase, Laura!
Status: RESOLVED → VERIFIED
Hey, because of this preview images and installation buttons are all completely broken in the add-ons manager.
Severity: minor → blocker
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(In reply to comment #8) > Yep, look at e.g. > https://services.addons.mozilla.org/en-US/firefox/api/1.1/addon/6534 > compare to same page on preview (when preview is up again) > The icon, thumbnail, and install urls should be on SAMO not on AMO. Verifying by inspection is probably necessary in this case. But we should also be verifying that the Add-ons manager is still working with the new data. I'd be happy to make some notes on how to do so if there is somewhere appropriate to put them.
Dave - if you can poke something in http://wiki.mozilla.org/Update:Remora_Testing that would be awesome. In the meantime, I've filed a blocker IT bug to revert the config change for SITE_URL so images/files will point to AMO until we sort out the right solution.
SAMO fixed in AMO prod, the images point to AMO as well as downloads. We need to make sure to QA the add-ons manager with the new XML anytime we flip the domains next time. So if we want to achieve 100% separation we'll probably need to allow preview images and downloads to go through SAMO. Right now their denied via apache.
(In reply to comment #13) > So if we want to achieve 100% separation we'll probably need to allow preview > images and downloads to go through SAMO. Right now their denied via apache. This is easy to do...
That's great, Reed. We'll take a look at it next week and QA it appropriately. Go have a weekend.
(In reply to comment #15) > That's great, Reed. We'll take a look at it next week and QA it appropriately. > Go have a weekend. Weekend? What's that? I have things to fix! :)
We should also consider how this affects download counts before we switch it back. So we shouldn't rush and change it back to SAMO at this point until we've had more discussion about metrics and QA.
IT - how important is it that images and downloads come only from SAMO?
Assignee: laura → morgamic
Target Milestone: 3.4.6 → 3.4.3
(In reply to comment #18) > IT - how important is it that images and downloads come only from SAMO? I won't speak for Justin, but comment #2 does say they must be 100% self-sufficient, and that requirement hasn't changed, afaik. SAMO and AMO are not both on the same cluster machines, so it's important to have them separated so if AMO goes down, it doesn't take SAMO down with it.
I'd like to see images on a CDN at some point, but downloads should be easily doable on SAMO. Laura - does it make sense to add controller actions to the API that serve images and files?
morgamic, I think that will add load we don't need. I would vote for just re-enabling images and file serving from here for now and moving them onto the CDN as soon as IT is done building it. When is that due, Reed?
It'd really be great to separate these out 100%, for cdn and just general load tracking and scaling. CDN is a ways out - is this a huge amount of work? I'd rate it as a really-nice-to-have, but not worth months of dev effort.
(In reply to comment #22) > It'd really be great to separate these out 100%, for cdn and just general load > tracking and scaling. Still separately for SAMO and AMO itself then, or having both point to the same place (like images.addons.mozilla.org or so)?
samo and amo completely self contained - i.e. no shared hostnames, so we could totally disable one or see the load from one vs the other. if there is some architecture reason this can't happen, I am all ears.
Nah, I don't see a problem with that. It just means we'd need to keep two separate copies of the very same image files, one for AMO to access, the other for SAMO.
3.4.5 was pushed on Friday.
Assignee: morgamic → nobody
Priority: -- → P2
Target Milestone: 3.4.3 → 4.x (triaged)
Is this still necessary? If so it can be fixed in Zamboni by IT in settings_local.py
Status: NEW → RESOLVED
Closed: 14 years ago → 12 years ago
Resolution: --- → FIXED
12 years ago
Assignee: nobody → dd
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.