feat: Rename dev.down to dev.remove-containers. (#1021)

This also adds some help text and updates documentation.

Author: dianakhuang

Makefile

@@ -359,10 +359,16 @@ dev.kill.%: ## Kill specific services.
 dev.rm-stopped: ## Remove stopped containers. Does not affect running containers.
 	docker-compose rm --force
 
-dev.down: ## Stop and remove containers and networks for all services.
+dev.down: ## Documentation for a change to naming
+	@echo "dev.down has been renamed to dev.remove-containers. If this doesn't seem like what you were looking for, you probably want to be using dev.stop instead. See docs for more details."
+
+dev.down.%:
+	@echo "dev.down has been renamed to dev.remove-containers. If this doesn't seem like what you were looking for, you probably want to be using dev.stop instead. See docs for more details."
+
+dev.remove-containers: ## Stop and remove containers and networks for all services.
 	docker-compose down
 
-dev.down.%: ## Stop and remove containers for specific services.
+dev.remove-containers.%: ## Stop and remove containers for specific services.
 	docker-compose rm --force --stop $$(echo $* | tr + " ")
 
 

docs/devpi.rst

@@ -16,7 +16,7 @@ requirements of all Devstack applications.
 In general the operation of devpi should be transparent. You may notice
 some significant speedup in tox testing and ``paver update_prereqs``
 operations after the first run. Container storage should persist through
-``make dev.down`` and ``make dev.up.<service>`` operations.
+``make dev.remove-containers`` and ``make dev.up.<service>`` operations.
 
 The devpi web interface can be browsed from the host at:
 http://localhost:3141/

docs/devstack_faq.rst

@@ -42,7 +42,7 @@ manually install or upgrade Python packages in a container (via
 ``pip install``, ``paver install_python_prereqs``, etc.), they will no
 longer be present if you restart the container.  (Devstack Docker containers
 lose changes made to the filesystem when you reboot your computer, run
-``make down``, restart or upgrade Docker itself, etc.) If you want to ensure
+``make remove-containers``, restart or upgrade Docker itself, etc.) If you want to ensure
 that your new or upgraded packages are present in the container every time it
 starts, you have a few options:
 
@@ -259,7 +259,7 @@ database migrations and package updates.
 
 When switching to a branch which differs greatly from the one you've been
 working on (especially if the new branch is more recent), you may wish to
-halt and remove the existing containers via ``make down``, pull the latest Docker
+halt and remove the existing containers via ``make remove-containers``, pull the latest Docker
 images via ``make dev.pull.<service>``, and then re-run ``make dev.provision.<service>``
 in order to recreate up-to-date databases, static assets, etc.