In order that we can serve the UI on Heroku, we wrap the Django wsgi app
with WhiteNoise, so both the UI and API requests are served by gunicorn.
In the Vagrant environment, Apache has been removed and Varnish instead
now proxies all requests to gunicorn/Django runserver directly, without
Apache as a go-between.
The UI on production will not be affected by this commit, since the
Apache config there will still intercept requests for the UI assets
rather than proxying them to gunicorn.
It's worth noting too, that we're not able to make use of WhiteNoise's
automatic Django GZip/caching support since that assumes we are using
Django templates and referring to resources using {% static "foo.css" %}
However, we can sub-class WhiteNoise (or more specifically the
DjangoWhiteNoise class) and override the is_immutable_file() method to
add caching support at a later date:
http://whitenoise.evans.io/en/latest/base.html#caching-headers
Documentation for WhiteNoise can be found at:
http://whitenoise.evans.io/
It's sometimes useful to be able to spin up an additional Vagrant
environment without affecting the first. To do this, we create two named
machines, both identical (since they inherit the main Vagrantfile
configuration) - one called default (to match the machine name used up
until now, so we don't force people to recreate their existing VMs when
we land this) and one called scratch.
The former is set to be the primary, so that single-machine commands
(eg `vagrant ssh`) work without having to append the machine name every
time.
The scratch machine has autostart set to false, so that it does not spin
up without explicitly using: `vagrant up scratch`
The name `scratch` is entirely arbitrary, and we can add additional
temporary machine names later, if people wish to have more than two
environments saved simultaneously.
For more information, see:
http://docs.vagrantup.com/v2/multi-machine/
This uses the newer image from:
https://vagrantcloud.com/ubuntu/boxes/trusty32
This also updates us from apache 2.2 to apache 2.4, which means the
apache config must be changed to be compatible with apache 2.4:
http://httpd.apache.org/docs/2.4/upgrading.html
(The syntax for "Allow from all" has changed, plus the default config
now specifies a "Require all denied" which we have to override for the
UI directory)
The only remaining difference between production.pp and vagrant.pp is
that the former uses a different local settings file
(local.production.py), which also outputs to the syslog. However we
don't need this for the local development environment, and nothing in
production is using the in-repo puppet, so it is no longer required.
One of the few differences between vagrant.pp and production.pp is from
which directory the UI is served. This change adds the ability to toggle
the directory from the Vagantfile directly, thereby bringing
production.pp (and the duplication it brings) closer to being obsolete.
The 'treeherder-service' repo has been renamed to 'treeherder', ready
for when the treeherder-ui repo is imported into it. This means the
Github URL, Travis URL and directory name when cloned changes. The Read
The Docs URL cannot be changed, so for now we will leave as-is, and in
the future (once service and UI docs combined) we will create a new
project on RTD with name "treeherder".
This updates doc links and puppet/Vagrant configs, but leaves the
stage/prod deploy script alone, since renaming the directories on our
infra is non-trivial. The dev instance will need some TLC since unlike
stage/prod, it does use the puppet scripts in the repo.
Ed Morley
Jonathan French
Cameron Dawson
mdoglio
Jonathan Eads