Remove redirect on preview.addons.mozilla.org

RESOLVED FIXED

Status

Infrastructure & Operations
WebOps: Other
--
major
RESOLVED FIXED
11 years ago
5 years ago

People

(Reporter: clouserw, Assigned: aravind)

Tracking

Details

(Reporter)

Description

11 years ago
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.
OS: Other → All
(Reporter)

Updated

11 years ago
Severity: normal → major
(Assignee)

Updated

11 years ago
Assignee: server-ops → aravind
(Assignee)

Comment 1

11 years ago
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

11 years ago
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? 
(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.
(Reporter)

Comment 4

11 years ago
Please ignore the "cron job to update" part of this request then.  Thanks. :)
(Assignee)

Comment 5

11 years ago
(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

11 years ago
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.)
(Reporter)

Comment 7

11 years ago
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?
(Assignee)

Comment 8

11 years ago
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.

(Assignee)

Comment 9

11 years ago
its now pointing to its own r/w db instance on mrdb03
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
(Reporter)

Comment 10

11 years ago
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
Component: Server Operations: Web Operations → WebOps: Other
Product: mozilla.org → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.