662547 - push developer.mozilla.org 0.9.5

Status: VERIFIED FIXED

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

Description

[Luke Crouch [:groovecoder]]

ETA June 7 (today - sorry)

IRC: #mdn

http://etherpad.mozilla.org:9000/MUYuZxMrs5

Comment 1

[Luke Crouch [:groovecoder]]

After 3pm PST.

Comment 2

[Jake Maul [:jakem]]

This will most likely be at 4pm. AMO and SUMO already have pushes at 2pm and 3pm, respectively.

Comment 4

[Jake Maul [:jakem]]

Completed. See etherpad for output.

2 small problems encountered. Ones was that it would not allow a rebase to be done because we had uncommitted local changes. This was fixed by:

git rm -r lib/product_details_json/ (the affected dir... probably unnecessary)
git fetch
git reset --hard

then the pull/rebase:
git pull --rebase origin mdn_prod



The other problem is a cron timing/location issue with the update_product_details job. The django data initially is updated in /data/dekiwiki_python/src (location 1), and from there is rsync'd over to /data/dekiwiki/django (location 2), where the MT and phpbb parts live. This whole tree is then added to a local git repo which the servers then pull from on a schedule (location 3).

The cron job currently updates the product_details dir in location 2. This means it's auto-updated to prod, within a few minutes of the product_details getting updated.

This works fine 99% of the time, but fails during a manual push (like this). It gets wiped out by that rsync copying from location 1.

We are working on a solution (obviously lots of things would work). Most likely, I will just add a step to the push instructions, rather than fiddle with the crons or scripts. This seems like the most obvious, straightforward solution- infra folks are used to seeing "update_product_details" during pushes, so it won't come as a shock to anyone.

Comment 5

[raymond [:retornam] (inactive)]

verified fixed http://developer.mozilla.org