I was having problems where concurrent installs could trample on each
other.  The instance that immediately affected me was output caching
from ec2.py: the output of that command is different between staging and
prod, and both were being written to /tmp/ansible_ec2.cache and .index.

Fix here is to write to a local temp directory.  This creates empty temp
dirs to ensure that they are created in all repos.

While less likely, you could have collisions on named ssh sockets.
Those are named with just the instance name, which could be re-used
across VPC's.  Putting those in the ./tmp dir too prevents that.

Note that for consistency I did away with just the plain ec2.ini file,
and instead now there are prod- and stage- variants.  This is clean but
now means that you'll need to change your install command to look
something like this:

    ANSIBLE_EC2_INI=prod-ec2.ini ANSIBLE_CONFIG=prod-ansible.cfg ansible-playbook -c ssh -u ubuntu -i ./ec2.py prod-app.yml

Conflicts:

	playbooks/edx-west/ansible.cfg

Added a validation on the machine variable, expected to be passed in
from the command line now, so that the worker play only works on
machines named "util" and the app play on machines named "app".
Otherwise it would be too easy to mix those up.

Now that we're using -e command line options, it's easier to use this to
specify the "modify_db" variable than prompt_vars.  Having every install
block on this question before was such a hassle!  Now we just won't
migrate unless you explicitly say so on the ansible command with
"migrate_db=yes" or "migrate_only=yes".

Conflicts:
	playbooks/edx-west/carnegie-prod-app.yml
	playbooks/edx-west/carnegie-prod-worker.yml
	playbooks/edx-west/cme-prod-app.yml
	playbooks/edx-west/cme-prod-worker.yml
	playbooks/edx-west/stage-app.yml

Conflicts:
	playbooks/edx-west/prod-app.yml
	playbooks/edx-west/prod-worker.yml
	playbooks/edx-west/stage-app.yml
	playbooks/edx-west/stage-worker.yml

It's handy to be able to create users that *don't* have sudo rights.
Here at Stanford we use this to add users to our VPC bastion box (ssh
proxy) so these users can use this machine for ssh tunneling, but I
don't want to give those users the keys to the kingdom.

This let's me configure a playbook like this.

   roles:
     - common
     - supervisor
     - role: gh_users
       gh_users:
         - su1
         - su2
         - su3
       gh_users_no_sudo:
         - normal1
         - normal2

The new gh_users_no_sudo list can be empty.

While in here do a couple of cleanups:

- remove a log file
- add a simple playbook for refreshing roles on the prod log machine

Re-enable set by command-line option and environment file.  We need this
at Stanford so we can get private DNS names to use with VPC's.

The only interesting change is moving the option parsing up a bit.

* /mnt/logs crept into the common recipes, when logs should be written
  to wherever {{log_base_dir}} says

The notifier isn't ready yet, needs theming to be done before it can be
installed.

removing git accounts for notifier repo, open now

add datadog api key Since this file will be the model for others
to use for their vars files, put in a placeholder DD api key, since
it's required to be *something* currently.

celerybeat wants to write its pidfile to ~notifier/src.  Not sure why
the PID or CELERYD_PID_FILE environment variables don't correctly point
it to /var/run/... but in the meantime, this should get us by.

notifier: remove git_ssh wrapper not needed now that repo is public

run notifier on first util machine only

remove references to forums_digest.sh. File was a vestige of prior
code when this was run from cron instead of celery beat.

Set carnegie local relative to carnegie secure, so we have to get the
prefixes right once only.

They have their own LMS DB.

If the nginx play is called with the nginx_conf varialble, then expect
to find in {{secure_dir}}/files/nginx.conf and copy it over.  If not set
then the default one already there will be sufficient.

Not checking those symlinks in since they are symlinks to another repo,
but generally people will want these.  On my machine they look like
this:
    configuration-secure@ -> ../../../configuration-secure
    edx-secret@ -> ../../../configuration-secure

Just for the edx-west configuration files.

Just to facilitate user updates to the jumpboxes.

Committer: jbau <jbau@stanford.edu>