bug 1352232: Remove Vagrant from docs

Remove references to Vagrant from the documentation, and fix some small
documentation issues:

- Update status of Dockerization
- Move subjects under Advanced Configuration up, so they appear in
  sidebars
- Update the docs for updating localization files to reflect my current
  process
- Convert performance testing instructions to Docker

.dockerignore

@@ -61,6 +61,7 @@ bower_components
 build.py
 developer.mozilla.org.tar.gz
 docker-compose.dev.yml
+docker-compose.locust.yml
 humans.txt
 james.ini
 kuma/static/js/libs/ckeditor/source/ckbuilder

.gitignore

@@ -58,6 +58,7 @@ bower_components
 build.py
 developer.mozilla.org.tar.gz
 docker-compose.dev.yml
+docker-compose.locust.yml
 humans.txt
 james.ini
 kuma/static/js/libs/ckeditor/source/ckbuilder

docs/celery.rst

@@ -56,8 +56,6 @@ available to async tasks, and web code can easily schedule async tasks.
 
 In Docker, the worker process runs in the ``worker`` service / container.
 
-In Vagrant, the worker process is started with the ``foreman`` command.
-
 Broker
 ------
 Celery requires a `message broker`_ for task communication. There are two stable,
@@ -70,7 +68,7 @@ production-ready alternatives:
 * RabbitMQ_ is an AMQP_ message broker written in Erlang_. The Celery team has
   recommended it for a long time, and the docs describe it as
   "feature-complete, stable, durable and easy to install". It is used in the
-  Vagrant and production environments.
+  production environment.
 
 .. _AMQP: https://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol
 .. _Celery: http://celeryproject.org/
@@ -101,9 +99,9 @@ Periodic tasks are scheduled with `celery beat`_, which adds tasks to the task
 queue when they become due.  It should only be run once in a deployment, or
 tasks may be scheduled multiple times.
 
-It is run in the Docker and Vagrant environments by running the single celery
-worker process with ``--beat``.  In production, there are several task workers,
-and the ``celery beat`` process is run directly on just one worker.
+In Docker, it runs in the ``worker`` container by starting the celery process
+with ``--beat``.  In production, there are several task workers, and the
+``celery beat`` process is run directly on just one worker.
 
 The schedules themselves are configured using the deprecated `django-celery`_
 database backend.  The work to replace this is tracked in `bug 1268256`_.
@@ -123,8 +121,7 @@ It is not part of the default Docker services, but can be started inside the
 
     ./manage.py celerycam --freq=2.0
 
-In the Vagrant environment, ``celerycam`` is started with other Kuma services
-with ``foreman``.
+In production, ``celerycam`` is run directly on one worker.
 
 For more options, see the `Monitoring and Management Guide`_ in the Celery
 documentation.
@@ -140,9 +137,9 @@ overridden by the environment variables, including:
 
 - CELERY_ALWAYS_EAGER_
 
-  Default: ``false`` (Docker), ``true`` (Vagrant, tests).
+  Default: ``False`` (Docker), ``True`` (tests).
 
-  When ``true``, tasks are executed immediately, instead of being scheduled and
+  When ``True``, tasks are executed immediately, instead of being scheduled and
   executed by a worker, skipping the broker, results store, etc. In theory,
   tasks should act the same whether executed eagerly or normally. In practice,
   there are some tasks that fail or have different results in the two modes,

docs/ckeditor.rst

@@ -19,11 +19,11 @@ This builds CKEditor within a Docker VM, using the Java ``ckbuilder`` tool
 from CKSource, then builds static resources so that the updated editor
 is installed where it belongs.
 
-To rebuild CKEditor from a ``vagrant ssh`` shell (or locally if you have Java
-installed)::
+To rebuild CKEditor locally, if you have Java installed::
 
     cd kuma/static/js/libs/ckeditor/source/
     ./build.sh
+    docker-compose exec web make build-static
 
 Portions of the build process will take a few minutes so don't expect an
 immediate result.

docs/development.rst

@@ -2,27 +2,8 @@
 Development
 ===========
 
-Pick an environment
-===================
-There are two development environments, and you need to install at
-least one of them first.
-
-* The :doc:`Docker containerized environment <installation>` is the
-  preferred development environment. The Docker images are already provisioned,
-  so setup is faster. It is a better model for the production environment, and
-  after the planned rehost will be almost exactly the same. It does not yet
-  have all of the features of the Vagrant environment, and it is currently
-  slower for many development tasks.
-* The :doc:`Vagrant-managed VM <installation-vagrant>` is the mature but
-  deprecated development environment. It can be tricky to provision. It is
-  often a poor model for the production environment, and can not be used to
-  test infrastructure changes.
-
-Docker and Vagrant can be used at the same time on the same "host machine" (your
-laptop or desktop computer).
-
 Basic Docker usage
-------------------
+==================
 Edit files as usual on your host machine; the current directory is mounted
 via Docker host mounting at ``/app`` within the ``kuma_web_1`` and
 other containers. Useful docker sub-commands::
@@ -43,36 +24,12 @@ There are ``make`` shortcuts on the host for frequent commands, such as::
 
 Run all commands in this doc in the ``kuma_web_1`` container after ``make bash``.
 
-Basic Vagrant usage
--------------------
-Edit files as usual on your host machine; the current directory is
-mounted via NFS at ``/home/vagrant/src`` within the VM. Updates should be
-reflected without any action on your part. Useful vagrant sub-commands::
-
-    vagrant ssh     # Connect to the VM via ssh
-    vagrant suspend # Sleep the VM, saving state
-    vagrant halt    # Shutdown the VM
-    vagrant up      # Boot up the VM
-    vagrant destroy # Destroy the VM
-
-Run all commands in this doc on the VM after ``vagrant ssh``.
-
 Running Kuma
 ============
 When the Docker container environment is started (``make up`` or similar), all
 of the services are also started. The development instance is available at
 http://localhost:8000.
 
-The Vagrant environment runs everything in a single VM. It runs MySQL,
-ElasticSearch, Apache, and other "backend" services whenever the VM is running.
-There are additional Kuma-specific services that are configured in
-``Procfile``, and are run with::
-
-    foreman start
-
-The Vagrant development instance is then available at
-https://developer-local.allizom.org.
-
 Running the tests
 =================
 One way to confirm that everything is working, or to pinpoint what is broken,
@@ -192,8 +149,8 @@ this approach the next time they're upgraded.
 
 .. _Bower: http://bower.io
 
-Advanced configuration
-======================
+Customizing with Environment Variables
+======================================
 `Environment variables`_ are used to change the way different components work.
 There are a few ways to change an environment variables:
 
@@ -221,8 +178,8 @@ around 4 seconds to page load time.
 
 .. _advanced_config_docker:
 
-The Docker environment
-----------------------
+Customizing the Docker Environment
+==================================
 Running docker-compose_ will create and run several containers, and each
 container's environment and settings are configured in ``docker-compose.yml``.
 The settings are "baked" into the containers created by ``docker-compose up``.
@@ -236,7 +193,7 @@ loads the Werkzeug debugger on exceptions (see docs for runserver_plus_), and
 that allows for stepping through the code with a debugger.
 To use this alternative, create an override file ``docker-compose.dev.yml``::
 
-    version: "2"
+    version: "2.1"
     services:
       web:
         command: ./manage.py runserver_plus 0.0.0.0:8000
@@ -267,57 +224,12 @@ documentation for more ideas on customizing the Docker environment.
 .. _pdb: https://docs.python.org/2/library/pdb.html
 .. _runserver_plus: http://django-extensions.readthedocs.io/en/latest/runserver_plus.html
 
-.. _vagrant-config:
-
-The Vagrant environment
------------------------
-It is easiest to configure Vagrant with a ``.env`` file, so that overrides are used
-when ``vagrant up`` is called.  A sample ``.env`` could contain::
-
-    VAGRANT_MEMORY_SIZE=4096
-    VAGRANT_CPU_CORES=4
-    # Comments are OK, for documentation and to disable settings
-    # VAGRANT_ANSIBLE_VERBOSE=true
-
-Configuration variables that are available for Vagrant:
-
-- ``VAGRANT_NFS``
-
-  Default: ``true`` (Windows: ``false``)
-  Whether or not to use NFS for the synced folder.
-
-- ``VAGRANT_MEMORY_SIZE``
-
-  The size of the Virtualbox VM memory in MB. Default: ``2048``.
-
-- ``VAGRANT_CPU_CORES``
-
-  The number of virtual CPU core the Virtualbox VM should have. Default: ``2``.
-
-- ``VAGRANT_IP``
-
-  The static IP the Virtualbox VM should be assigned to. Default: ``192.168.10.55``.
-
-- ``VAGRANT_GUI``
-
-  Whether the Virtualbox VM should boot with a GUI. Default: ``false``.
-
-- ``VAGRANT_ANSIBLE_VERBOSE``
-
-  Whether the Ansible provisioner should print verbose output. Default: ``false``.
-
-- ``VAGRANT_CACHIER``
-
-  Whether to use the ``vagrant-cachier`` plugin to cache system packages
-  between installs. Default: ``true``.
-
-The database
-------------
+Customizing The database
+========================
 The database connection is defined by the environment variable
-``DATABASE_URL``, with these defaults::
+``DATABASE_URL``, with this default::
 
-    DATABASE_URL=mysql://kuma:kuma@localhost:3306/kuma              # Vagrant
-    DATABASE_URL=mysql://root:kuma@mysql:3306/developer_mozilla_org # Docker
+    DATABASE_URL=mysql://root:kuma@mysql:3306/developer_mozilla_org
 
 The format is defined by the dj-database-url_ project::
 
@@ -334,8 +246,8 @@ To connect to the database specified in ``DATABASE_URL``, use::
 
 .. _dj-database-url: https://github.com/kennethreitz/dj-database-url
 
-Asset generation
-----------------
+Generating Production Assets
+============================
 Kuma will automatically run in debug mode, with the ``DEBUG`` setting turned to
 ``True``. Setting ``DEBUG=False`` will put you in production mode and
 generate/use minified (compressed) and versioned (hashed) assets. To
@@ -347,8 +259,8 @@ emulate production, and test compressed and hashed assets locally:
 #. Run ``docker-compose exec web make build-static``.
 #. Restart the web process using ``docker-compose restart web``.
 
-Secure cookies
---------------
+Using Secure cookies
+====================
 To prevent error messages like "``Forbidden (CSRF cookie not set.):``", set the
 environment variable::
 
@@ -359,7 +271,7 @@ HTTPS.
 
 
 Deis Workflow Demo instances
-----------------------------
+============================
 You can deploy a hosted demo instance of Kuma by following these steps:
 
 #. Create a new branch, you cannot create a demo from the ``master`` branch.
@@ -388,12 +300,10 @@ to the MySQL instance::
 wondering why the commands don't appear in your bash history, it's because there's
 whitespace at the beginning of the line.
 
-
-
 .. _maintenance-mode:
 
 Maintenance Mode
-----------------
+================
 Maintenance mode is a special configuration for running Kuma in read-only mode,
 where all operations that would write to the database are blocked. As the name
 suggests, it's intended for those times when we'd like to continue to serve
@@ -443,7 +353,7 @@ them against your local Docker instance, first do the following:
 #. Load the latest sample database (see :ref:`provision-the-database`).
 #. Ensure that the test document "en-US/docs/User:anonymous:uitest" has been
    rendered (all of its macros have been executed). You can check this by
-   browsing to `http://localhost:8000/en-US/docs/User:anonymous:uitest`_. If
+   browsing to http://localhost:8000/en-US/docs/User:anonymous:uitest. If
    there is no message about un-rendered content, you are good to go. If there
    is a message about un-rendered content, you will have to put your local
    Docker instance back into non-maintenance mode, and render the document:
@@ -455,7 +365,7 @@ them against your local Docker instance, first do the following:
 
    * ``docker-compose up -d``
    * Using your browser, do a shift-reload on
-     `http://localhost:8000/en-US/docs/User:anonymous:uitest`_
+     http://localhost:8000/en-US/docs/User:anonymous:uitest
 
    and then put your local Docker instance back in maintenance mode:
 
@@ -487,4 +397,3 @@ Now you should be ready for a successful test run::
 Note that the "search" tests are excluded. This is because the tests marked
 "search" are not currently designed to run against the sample database.
 
-.. _http://localhost:8000/en-US/docs/User:anonymous:uitest: http://localhost:8000/en-US/docs/User:anonymous:uitest

docs/elasticsearch.rst

@@ -37,7 +37,7 @@ This process works both in a development environment and in production:
   (the top most) and select "Populate selected search index via Celery" from
   the Action dropdown menu. Click "Go" to start indexing asynchronously.
 
-- In the development environment, you can watch the indexing process with:
+- In the development environment, you can watch the indexing process with::
 
     docker-compose logs -f elasticsearch worker
 

docs/index.rst

@@ -24,5 +24,3 @@ Contents:
    localization
    ckeditor
    documentation
-
-   installation-vagrant