1387104 - [tracker] make running webapp and processor in docker environment useful

Status: RESOLVED FIXED

(Socorro :: General, task)

Description

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

A couple of months ago, we hobbled together the basic bits for a docker-based dev environment.

In bug #1368698, we focused on bugs found in common use cases for running the tests in a docker environment.

This tracker covers focusing on bugs found in common use cases for running the webapp and processor in a docker environment.

Comment 1

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

Here are some rough goals for this tracker:

1. After running "make dockerbuild" and "make dockersetup", running "docker-compose up webapp" should run a webapp that works for basic things

   1.1. you should be able to view the default product page
   1.2. views that don't require crash data should work

2. After running "make dockerbuild" and "make dockersetup", running "docker-compose up processor" should run a processor that works for basic things

   2.1. you should be able to process a crash that you can then see with the webapp

Comment 2

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

We need to improve the instructions regarding where to put environment variable overrides that are specific to a host or whatever a developer is working on.

For example:

1. oauth-related bits for the webapp
2. hosts and ports to use

Comment 3

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

Fixing blockers. I keep setting things up backwards. :(

Comment 4

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

We've done a ton of work on the scaffolding, configuration, scripts, and documentation. The end result is that we're probably pretty close.

One thing we know is still busted is supersearch fields. In -stage and -prod these are stored in Elasticsearch. Bug #1100354 covered moving supersearch fields to a JSON file that's versioned along with everything else in the repository. That requires us to be using Elasticsearch 5.x. We're going to try another Elasticsearch 1.x to 5.x migration this week. If that works out, then the fix for bug #1100354 will land and our problem with supersearch fields goes away. Making this depend on bug #1100354.

Once that's resolved, I'm betting we'll hit some other issues, but we can tackle them in future bugs.

Comment 5

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

We did a ton of work on this in 2017 q3. I looked through the remaining bugs and changed them so they no longer block this bug. I'm declaring this done!