973998 - Telemetry experiments: initial server

Status: VERIFIED FIXED

(Firefox Health Report Graveyard :: Web: Health Report, defect)

Description

[Benjamin Smedberg]

The server code should deploy static files. Currently this means a manifest of experiments. This depends on deciding the URL scheme in bug 973997. Laura says we should probably use the same basic deployment structure that the FHR server does.

Laura when should I file separate bugs to get a staging environment set up?

Comment 1

[Benjamin Smedberg]

For version 1 this also needs to publish a basic HTML list of current and past experiments with links to their XPIs and their deployment details.

I'm warming up to the idea of checking the .xpis into source control so that we have the archive of them and can just ship them from the same site as the manifest and everything else.

Comment 2

[Laura Thomson :laura]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #0)
> The server code should deploy static files. Currently this means a manifest
> of experiments. This depends on deciding the URL scheme in bug 973997. Laura
> says we should probably use the same basic deployment structure that the FHR
> server does.
> 
> Laura when should I file separate bugs to get a staging environment set up?

ASAP, probably about six weeks ago ;)

Comment 3

[Laura Thomson :laura]

Also: yes, put the xpis in source control.

Comment 4

[Gregg Lind (Fx Strategy and Insights - Shield - Heartbeat )]

Ben, I don't require list of past experiments.  Is that a privacy thing?  Or a niceness?  

nice to have:  For xpi's, it would also be nice if the place they are deployed from allows proper `update.rdf` stuff, has x-xpiinstall header, and has some logging around download stats.

Comment 5

[Benjamin Smedberg]

The historical archive is mainly a thing to keep the project reasonably open. We may also need to link to the source for each experiment for licensing reasons.

Good point about the XPIs. Actually how I think that will work is that experiment XPIs won't check for updates at all; all updating will be managed via the experiment system itself. But I'll file a work item to make sure that actually works properly.

I do expect we'll have basic logging abilities: do we need to record anything other than aggregate hits per URL?

Comment 6

[Benjamin Smedberg]

http://hg.mozilla.org/users/bsmedberg_mozilla.com/telemetry-experiment-server/ has an initial template of code that webops is using for initial deployment.

Comment 7

[Gregory Szorc [:gps]]

You should open files in binary mode when used with json.write() otherwise Unicode may not be preserved.

Comment 8

[Gregory Szorc [:gps]]

Why is this assigned to me?

Comment 9

[Benjamin Smedberg]

You are the available engineer who knows python and can do this.

Comment 10

[Gregory Szorc [:gps]]

We're not deploying Python on the server, are we? (At least not for v1.)

I ask because this influences the URL decisions.

The goal is to have the HTTP server (not Python) rewrite all manifest URLs to a single file for the short term and to deploy more complex logic later (as needed), right?

Comment 11

[Benjamin Smedberg]

Correct. The prototype uses .htaccess and mod_rewrite to force URL accesses such as https://telemetry-experiment-dev.allizom.org/manifest/Firefox/28 to the .json file.

http://hg.mozilla.org/users/bsmedberg_mozilla.com/telemetry-experiment-server/file/13484b3fcbc3/templates/.htaccess

Comment 12

[Gregory Szorc [:gps]]

I'm not sure what version of Apache we're using. But last I checked, .htaccess had to be read on every request, adding request overhead. It's much better to put these things in the config file, which is parsed once at process start. I reckon we could generate a standalone file suitable for Include usage. But we'd need to know what else to put in the <VirtualHost>.

Until told otherwise, I'm assuming our servers can handle the .htaccess overhead.

Comment 13

[Gregory Szorc [:gps]]

Rob: I'm reaching out to you because I think you know the answer and I'm not sure who else besides lxt to reach out to and I don't want to burden her. Feel free to redirect.

We want to give web-y land the link to this repo (command #6) that contains a Python script that will be used to generate the htdocs for a server. Questions:

1) What Python restrictions (if any) are in place? I assume you're running a 2.7 stack and I can provide something with a setup.py or requirements.txt that you can virtualenv install and run a simple command?

2) What HTTP server are you running? We need to employ some URL rewriting. Not sure if I should target Apache, nginx, or other. Not sure if we should use a .htaccess or write out a config fragment to be included in the server config proper.

Comment 14

[Gregory Szorc [:gps]]

Redirecting to cturra.

Comment 15

[Chris Turra [:cturra]]

(In reply to Gregory Szorc [:gps] from comment #13)
> We want to give web-y land the link to this repo (command #6) that contains
> a Python script that will be used to generate the htdocs for a server.
> Questions:
> 
> 1) What Python restrictions (if any) are in place? I assume you're running a
> 2.7 stack and I can provide something with a setup.py or requirements.txt
> that you can virtualenv install and run a simple command?

this is running on our generic web cluster. opsec requires all our production services require signed package management, which means any packages need to come from an RPM hosted in our network. what are your requirements? we're currently running python 2.6 due to some package dependencies+rhel, but 2.7 is on our roadmap for this cluster - no eta on that yet tho. currently, this cluster does not use virtualenv's, the hosting is shared amongst a number of other applications. 


> 2) What HTTP server are you running? We need to employ some URL rewriting.
> Not sure if I should target Apache, nginx, or other. Not sure if we should
> use a .htaccess or write out a config fragment to be included in the server
> config proper.

we use apache with mod_wsgi.

Comment 16

[Benjamin Smedberg]

http://hg.mozilla.org/webtools/telemetry-experiment-server/rev/1b321d90f8c7

Comment 17

[Marco Mucci [:MarcoM]]

Hi Kamil, will verification of this bug be able to be completed before the end of our iteration on Monday April 14?

Comment 18

[Kamil Jozwiak [:kjozwiak]]

Went through the following verification using the latest Nightly build:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-04-09-03-02-03-mozilla-central/

Installed an experiment using the following staging servers:
- https://telemetry-experiment-dev.allizom.org/firefox-manifest.json (tested with OSX, Ubuntu, Windows)
- http://kamiljozwiak.com/firefox-manifest.json (tested with OSX, Ubuntu, Windows)
- http://localhost:8080/firefox-manifest.json (tested with OSX)

Used the following OS's while going through the verification process:
- Windows 8.1 x64 (Passed)
- Ubuntu 13.10 x64 (Passed)
- OSX 10.9.2 x64 (Passed)

* Enabled all the required pref's using about:config, you can use the following wiki as a guide:
- https://wiki.mozilla.org/User:Kjozwiak/Telemetry_Experiments_QA
* Once all the pref's have correctly been set, disabled/enabled "experiments.enabled"
* Ensured that the "Experiment" section was been added under about:addons
* Ensured that the correct addon is being listed under the "Experiment" category under about:addons
* Ensured that once you "uninstall" the addon experiment, the "Experiment" category under about:addons is being removed
* Ensured that the experiment is appearing under about:support (at the bottom of the page under the "Experiment" section)
* Ensured that the experiment under about:support appear as "true" while installed and "false" while uninstalled
* Ensured that experiments list is not being cleared under about:support (keeps 180 days worth of history)

Ensured that you can clone the staging server from the following link:
- http://hg.mozilla.org/webtools/telemetry-experiment-server/

* Ensured that you can clone without any issues
* Ensured that you can run the script and create a staging server without any issues/errors
* Ensured that the README file mentions all the needed prerequisites to successfully build the staging server

If there's something missing that should have tested, please change it back to "Resolved" and needinfo me!