1397534 - [ops infra socorro] working webapp in stage

Status: RESOLVED FIXED

(Socorro :: Infra, task, P2)

Description

[Miles Crabill [:miles]]

The webapp is currently deployed in ops stage at https://socorro.stage.mozaws.net/, however the main page does not load. After talking to :peterbe a while back, we guessed that this is because the database is unpopulated.

The current plan is to copy the webeng stage database (bug 1397531) over to the ops stage database and see whether things work better.

Comment 1

[Miles Crabill [:miles]]

An update to this bug: the main page, https://socorro.stage.mozaws.net/home/product/Firefox, loads successfully with static assets. The data in elasticsearch is (as of this writing) out of date, but several weeks ago when I populated it we had a mostly working page. The graphs looked different than the webeng stage webapp at the time, however.

Requirements for a working webapp in stage:
  - access to crash bucket in s3 (working with a new, empty bucket)
  - access to elasticsearch cluster in stage (bug 1399576)
  - access to memcached in stage (using elasticcache, working afaict)
  - access to postgres database in stage (using rds, working afaict, bug 1397531)
  - access rmq cluster (not done, bug 1406003)
  - working crontabber in stage (not done, bug 1406019)

Comment 2

[Will Kahn-Greene [:willkg] ET needinfo? me]

I talked to Miles earlier and he said the webapp in -stage-new is kicking up an HTTP 404 on the /home/product/Firefox page. Pretty sure that's either data missing from the lookup tables like product_versions.

The theory is that once we figure out crontabber issues and ADI issues, then the webapp will work itself out maybe.

If not, we should split this off into a new bug.

Comment 3

[Will Kahn-Greene [:willkg] ET needinfo? me]

Making this a P2. This needs to work in the new infra.

Comment 4

[Miles Crabill [:miles]]

The webapp works in the new infra. The only things outstanding that I can think of are:

- should the webapp be run with DJANGO_CONFIGURATION=Stage in stage and Prod in prod?
- should we block this bug on figuring out migrations?

Comment 5

[Will Kahn-Greene [:willkg] ET needinfo? me]

DJANGO_CONFIGURATION is an environment variable used by the django-configurations library (https://django-configurations.readthedocs.io/en/stable/). We don't use that library for configuration, so we don't need that environment variable.

"How do we do migrations during a deploy?" is covered in bug #1429850. I don't think it helps to block this bug on figuring that one out.

Comment 6

[Miles Crabill [:miles]]

Cool - yeah, I did some spelunking after my comment and realized that we don't use django-configurations.

I think we're good here.