Does so by running the edxapp role just to generate config (as
controlled by check-migrations.sh's use of the --tag) and then
the tasks in the playbook are hardcoded to always run, regardless
of the tag.  Because the edxapp play has run, the tasks have
access to the various config variables containing DATABASES
and can tell what DBs are in use.

Skip the read replica

Update the base fully bulit image as well as the 12.04 and 14.04 clean images.

Pip 8.0.0, released a few hours ago, tries to uninstall deb-installed
python modules that it wants to upgrade, and always fails when doing so.
The effect is that configuration/requirements.txt cannot be fulfilled,
notably ansible 1.9.3-edx, which requires an upgrade to pycrypto.

This forces the installation of pip to the latest one prior to 8.0.0,
7.1.2.

It also freezes setuptools and virtualenv, so that they should all match
the current versions required on
playbooks/roles/common_vars/defaults/main.yml:common_pip_pkgs.

Pip 8.0.0, released a few hours ago, tries to uninstall deb-installed
python modules that it wants to upgrade, and always fails when doing so.
The effect is that configuration/requirements.txt cannot be fulfilled,
notably ansible 1.9.3-edx, which requires an upgrade to pycrypto.

This forces the installation of pip to the latest one prior to 8.0.0,
7.1.2.

It also freezes setuptools and virtualenv, so that they should all match
the current versions required on
playbooks/roles/common_vars/defaults/main.yml:common_pip_pkgs.

Upgrading to Dogwood is complicated, because we have to make two
intermediate stops along the way: once at the end of Django 1.4 to
migrate the databases using South, then to the beginning of Django 1.8
to apply --fake-initial migrations.  Then we can upgrade to the Dogwood
release that we actually want.

ECOM-3181

This will give us the ability to run packer builds (which will
actually register an AMI) for the strict purpose of testing
the packer buildout itself. Currently, we only build an AMI
as-needed, and when we want to test the buildout, we must manually
delete the registered AMI if the build is successful. The ability
to tag according to testing or real-use will also allow us to
automatically deregister AMIs that were only being used for test
purposes, rather than actual Jenkins builds.

use the second if with NGINX_SET_X_FORWARDED_HEADERS

introduce new variable NGINX_REDIRECT_TO_HTTPS for redirect

simplify the logic

fixed the typo

change the if statement logic

nginx error fix

apply the last fixed to all the required templates

Auto confirm for gcc/g++ ppa

`sandbox.sh` hang at the step when it add the gcc/g++ ppa for user respone(yes/enter), you make it better to make it auto install without user interaction. Thanks

fix the shell if syntax

fix the shell if syntax

Revert "Auto confirm for gcc/g++ ppa"