Closed Bug 655032 Opened 13 years ago Closed 13 years ago

change developer-stage9 to kuma repos, mdn branch

Categories

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

All
Other
task
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: groovecoder, Assigned: nmaul)

References

()

Details

Assignee: server-ops → nmaul
The etherpad is as accurate as I can make it. We should vidyo thru this.
Severity: enhancement → major
Blocks: 641839
Completed. We'll be doing something similar later on for prod.

Here are the etherpad docs, in case that gets lost or deleted or changed. Most work was done on mradm02:/data/devmostage/src, but Apache configs are in puppet.


Add the new django dir
# written from sm-devmostage; adjust directories as necessary for mradm
cd /data/www/django
mkdir developer-stage9.mozilla.org
git clone git://github.com/mozilla/kuma.git developer-stage9.mozilla.org/kuma
cd developer-stage9.mozilla.org/kuma
git submodule update --init --recursive
git checkout mdn
all good up to here
ls -hal vendor/src/django
[root@mradm02 kuma]# ls -hal vendor/src/django
ls: vendor/src/django: No such file or directory
How do I fix?
git submodule update --init --recursive
done
# make sure it got all the submodules recursively
svn co http://svn.mozilla.org/projects/mdn/trunk/locale
done
Copy settings_local.py from "old" mdn dir:
cp developer.mozilla.org/mdn/settings_local.py developer-stage9.mozilla.org/kuma/settings_local.py
done
Create django resources
./manage.py update_product_details
./manage.py compress_assets
done
Change .htaccess symlink
/data/www/dekiwiki9/.htaccss -> ../django/developer-stage9.mozilla.org/kuma/configs/htaccess
done
Change developer-stage9.mozilla.org.conf:
-Alias /media /data/www/django/developer.mozilla.org/mdn/media
+Alias /media /data/www/django/developer-stage9.mozilla.org/kuma/media
-Alias /admin-media /data/www/django/developer.mozilla.org/mdn/vendor/packages/Django/django/contrib/admin/media
+Alias /admin-media /data/www/django/developer-stage9.mozilla.org/kuma/vendor/packages/Django/django/contrib/admin/media
-WSGIScriptAlias /mwsgi /data/www/django/developer.mozilla.org/mdn/wsgi/mdn.wsgi
+WSGIScriptAlias /mwsgi /data/www/django/developer-stage9.mozilla.org/kuma/wsgi/kuma.wsgi
done
Restart Apache
/etc/init.d/httpd restart
done
Test https://developer-stage9.mozilla.org/
When all is well:
Change stage_update script:
-pushd $STAGE_DIR/src/developer.mozilla.org/mdn > /dev/null
-./bin/update_staging.sh
done
+pushd $STAGE_DIR/src/developer-stage9.mozilla.org/mdn > /dev/null
+./scripts/update_site.py -e mdn_stage
popd > /dev/null
added
-pushd $STAGE_DIR/src/kuma-stage.mozilla.org/kuma/locale > /dev/null
-svn -q up
-popd > /dev/null
(update_site.py already does this)
verified / commented out
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Sorry I need to reopen because our apache config changes got lost on svm-devmostageNN boxes!
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
And the symlink disappeared?
The symlink was my fault, and is fixed now. As for the config... it looks normal to me. Has someone else already fixed this for you?
I believe you're looking at the wrong config file. The right one is:

/etc/httpd/mozilla/domains/developer-stage9.mozilla.org.conf

.... *not* the one in /etc/httpd/conf/domains/. I don't know where that's from, but if you diff them you'll see a couple other differences. If to trace through Apache's config starting at httpd.conf and running down the includes, only the ones in mozilla/domains are actually included.
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Reopening because there's still some weirdness. Like the django templates are cached ...

the template files have:
<script src="{{MEDIA_URL}}js/mdn/demos.js"

but the rendered pages have:
<script src="/media/js/demos.js" 
        type="text/javascript"></script>

http://screencast.com/t/beche61Y84Y

I don't know if it's HTML cached in zeus or django templates cached in memcache or something else but I'm leaving this bug open to track it.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I think this is good now
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Comment 7 apparently fixed by an Apache restart... whilst troubleshooting something unrelated on the same servers, Apache was restarted, and afterwards the the bug in comment 7 was no longer apparent. Just noting here in case it happens again later on (like on the equivalent 'prod' change that will happen soon).
Component: Server Operations: Web Operations → WebOps: Other
Product: mozilla.org → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.