Closed Bug 647068 Opened 13 years ago Closed 13 years ago

Point the automated blocklist update lander to the AMO staging server

Categories

(Release Engineering :: General, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ehsan.akhgari, Assigned: coop)

Details

(Whiteboard: [automation])

Attachments

(1 file)

Based on the discussion that we had with fligtar, RelEng should point the automated blocklist update lander bot to AMO's staging server for blocklist updates.
So what's the URL we should be pointing at?

This is the URL we are currently using:

http://hg.mozilla.org/build/tools/file/111bf8895346/scripts/blocklist/sync-hg-blocklist.sh#l80
Assignee: nobody → coop
OS: Mac OS X → All
Priority: -- → P3
Hardware: x86 → All
Whiteboard: [automation]
Looks like 

https://addons.allizom.org/blocklist/3/${APP_ID}/${VERSION}/${APP_NAME}/20090105024647/blocklist-sync/en-US/nightly/blocklist-sync/default/default/

based on instructions from https://wiki.mozilla.org/Blocklisting/Testing.  (Not sure if the date should be hardcoded in there ...)

Fligtar can confirm that.

Btw, thanks for filing this bug Ehsan, kinda dropped off my radar.
Replacing addons.mozilla.org with addons-next.allizom.org should do the trick. (addons-next is more stable than allizom code-wise but uses the same database)

Just want to confirm that if the script doesn't get a 200 response nothing really bad is going to happen, right?

As it is our staging server, it is down occasionally and other times (like today) we do database imports from production that can take hours.
Status: NEW → ASSIGNED
Priority: P3 → P2
Attachment #528682 - Flags: review?(bear) → review+
Looks like you're using addons.allizom instead of addons-next.allizom. As I mentioned in comment #3, that will work, but -next is going to be more stable.
Comment on attachment 528682 [details] [diff] [review]
Switch AMO blocklist URL to allizom, verify XML headers on retrieved files

(In reply to comment #5)
> Looks like you're using addons.allizom instead of addons-next.allizom. As I
> mentioned in comment #3, that will work, but -next is going to be more stable.

Re-tested before landing, and then landed with addons-next.allizom.org:

http://hg.mozilla.org/build/tools/rev/f1238a6321f3
Attachment #528682 - Flags: checked-in+
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
The blocklist updater that just ran on pm03 for mozilla-central still hit addons.m.o:

https://addons.mozilla.org/blocklist/3/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/6.0a1/Firefox/20090105024647/blocklist-sync/en-US/nightly/blocklist-sync/default/default/

Additionally, it removed quite a few entries:
 http://hg.mozilla.org/mozilla-central/rev/b430e631d5cd

This seems to be a genuine difference between staging and production amo. Is that expected fligtar ? The blocklist we're landing in the tree ends up in new users hands for their first run, and some time later they get the prod data. So that kinda requires the amo staging db not get out of sync with prod. How did we get to pointing at staging instead of prod ?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Querying prod again because of this backout:
 http://hg.mozilla.org/build/tools/rev/af245a1f1eab
 Comment - revert AMO blocklist URL to pull from live - r=bustage
OK, so this discussion should have happened in the bug, but transpired by email instead.

The last message was from Mossop:

> Justin mentioned to me that they sometimes block Flash in staging so they 
> can do testing. I don't think we want that shipping in even nightly builds 
> so I think until we're sure of the kinks in the system we should just go 
> the safer route and only pull from live for now.

If we figure out a stable way to update from staging, we will revisit this.
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: