375650 - Remove redirect on preview.addons.mozilla.org

Status: RESOLVED FIXED

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

Description

[Wil Clouser [:clouserw]]

Currently preview.addons.mozilla.org is redirecting to addons.mozilla.org.  We'd like to restore preview.addons.mozilla.org as a separate site, and also:

1) add a cronjob that `svn up`'s it every 5(?) minutes and restarts apache

2) Make sure memcache is enabled (a separate instance than production)

3) have preview.amo use the live database from addons.m.o.  (both will point at the same database)

Thanks.

Comment 1

[Aravind Gottipati [:aravind]]

A separate site located where?  Do you want this as a real preview site (as opposed to something on the stage.m.o infrastruture?). 

If you want this located on the real prod machines, then that first request of restarting apache every 5 minutes will not work.

Comment 2

[Cameron]

Personally, I'd be unhappy with this. Lots of sites linked to preview.addons.mozilla.org during the testing period (see http://www.google.com/search?q=preview.addons.mozilla.org+-site%3Apreview.addons.mozilla.org ) and users still clicking links leading there should not be greeted with whatever is being developed on trunk. 

Wouldn't addons.stage.mozilla.com be a better location for our staging needs?

Additionally, is using the same db the best idea? What about when we check in a change which requires schema changes? 

Comment 3

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

(In reply to comment #2)
> Personally, I'd be unhappy with this. Lots of sites linked to
> preview.addons.mozilla.org during the testing period (see
> http://www.google.com/search?q=preview.addons.mozilla.org+-site%3Apreview.addons.mozilla.org
> ) and users still clicking links leading there should not be greeted with
> whatever is being developed on trunk. 

We're not talking about whatever's being developed on trunk, we're talking about preview being used to test out a set of changes that we want to push to production.  remora.stage (or some renamed variant thereof like addons.stage) would be for the continuous integration of trunk.

> Additionally, is using the same db the best idea? What about when we check in a
> change which requires schema changes? 

The point is that preview verifies that things will work correctly on production, precisely so that we -can- effectively verify such schema changes before we publish to our millions of users.

We don't need to auto-update preview.a.m.o, IMO, but it should be on the production cluster and talking to the production DB.  We do want addons.stage updated frequently, either on demand due to a checkin on trunk or every N minutes.

Comment 4

[Wil Clouser [:clouserw]]

Please ignore the "cron job to update" part of this request then.  Thanks. :)

Comment 5

[Aravind Gottipati [:aravind]]

(In reply to comment #3)
> The point is that preview verifies that things will work correctly on
> production, precisely so that we -can- effectively verify such schema changes
> before we publish to our millions of users.

If you have situations that need an incompatible update of the db schema to test a preview release, then using the same prod db will not work.

In any case what you describe seems like it is more suitable for the existing stage.addons.m.o or some such location.  I see your point that you are currently using stage as a continuous refresh of the trunk from svn.  This is the wrong use of stage.  The original purpose of stage is to use it to "stage" production releases.

If you need another instance that you would use for dev work (so its continuously in sync with svn head), then that would probably be in a diff request.

Comment 6

[Justin Fitzhugh]

I think these are just mis-named - as I understand it:

kahn: dev, controlled by the developers
stage: r/o access for dev's, auto updated from HEAD, etc
preview: true stage environment - no access for devs, pushed by IT, final staging before release

Is this correct?  If so, let's get back to that state - seems like the machines are all allocated and permissions are setup correctly (just need the redirect removed.)

Comment 7

[Wil Clouser [:clouserw]]

justin: that's all correct.

I'll leave it up to shaver about pointing preview to the live database, but in the mean time, can we get the redirect removed, and preview.amo updated to the latest production tag for some final testing before we push again?

Comment 8

[Aravind Gottipati [:aravind]]

preview.addons.mozilla.org is now live.  It is pointing to a single server on the backend (mrapp08).  It has it own doc root that is currently an exact copy of the production addons docroot.

It is still however pointing to the same db as the production one does.  I will correct this before I close the bug.

Comment 9

[Aravind Gottipati [:aravind]]

its now pointing to its own r/w db instance on mrdb03

Comment 10

[Wil Clouser [:clouserw]]

Thanks Aravind.  Two more things:

Can you please `svn up` the site so it's in line with the current production tag?  (We're making sure our changes work before pushing them to a.m.o)

Can you fix the http -> https redirect so http://preview.addons.mozilla.org/ works again?

Thanks