This is needed so that we can properly build devstacks without passing in any other config.

3.0.14 was a bugfix release to 3.0.13
Changelog here, nothing particularly relevant to us, just the normal
march of progress and bugfixes.

https://docs.mongodb.com/v3.2/release-notes/3.0-changelog/#id1

ansible was upgraded to 2.2.0.0 version on master branch. login_database parameter is now supported

Mongo_3_0 is now ready for upgrading to Mongo 3.2 and keeping compatibility.
The fix is also necessary for Openstack deployment.

If this play is being run against an existing mmapv1 mongo 3.0 install,
make sure MONGO_STORAGE_ENGINE is overridden.

This will facilitate shipping 3.0 with newer release.

http://docs.mongodb.org/manual/release-notes/3.0

SERVER-22970  Background index build produces an index with mismatched
index keys and documents

Previously on this branch, it would attempt to create a superuser and
initialize the replica set after the local host exemption had passed
(once a mongod is started with a keyfile and the replicationSetName
 config file option or --replSet command line argument, you can't create
 users using the localhost exemption anymore ).

This necesarily complicates the logic and requires us to track if we're
initializing a replica set or not (with facts) and to template out
/etc/mongod.conf twice in the initialization case.

Further modifications to the replica set can be run against all the
members and will install mongo on new machines while updating the
replica set on the old machines.  With a further commit on this branch,
we can avoid needlessly restarting mongo on all machines in the cluster.

When we run this on an existing cluster, this stops and starts mongo for
all machines it is run against.  We can't rely on the notify: since that
happens at the end of the play and during initial cluster setup, we need
to restart and pick up the changed config.

Try to stick sensible tags on things

Ensure mongo restarts on the cluster key file change

Add a few playbook notes about common operations

Remove check for mongo 2.4 since this is the mongo_3_0 role
This was probably carried over from the mongo 2 role. I see no reason
why mongo 2.x and mongo 3 couldn't coexist on the same machine.

Remove old hugepages init script check
This was probably added while we were still iterating on our mongo 3
deployment, but it should no longer be necessary.

Clean up ansible syntax

Don't move the old mongo data dirs
This actually skips for edX because we provision machines that already
have {{mongo_data_dir}} mounted on an external disk.  However, for
non-edX use, this could fail if you turn on WiredTiger since it will
move mmapv1 files into the mongo_data_dir and then mongo will fail to
start because it has been told to use WiredTiger.

Don't make this a serial play
We usually run this on 3 machines, so serial: 3 was equivalent to
ansible's default of "run everything in parallel" but this causes
problems if you ever run it on 4 like we do for prod envs.
In addition, this prevents run_once from working properly, and there are
a number of things we only one to do on one machine (like creating a
superuser).

https://groups.google.com/forum/#!topic/mongodb-announce/mBesDEtR5l0

Additionally, it includes the fix for TOOLS-939 so we should not need to
pin to 3.0.6 any more.

We were ending up with gaps in our logs on disk (everything was in
splunk, but missing in /edx/var/log/mongo).  When this ran previously
and roatated serverStatus.log but mongodb.log was less than 1M and
didn't need to rotate, the killall -USR1 to mongo would cause the log to
be reopened and written over.

We can't use the 3.0.7 tools (mongodump/mongorestore) because of bugs in
the restore on gridfs and even draft mongo modulestore.
https://jira.mongodb.org/browse/TOOLS-939

This does not affect the mongo shell version

The * was rotating already rotated logs
OPS-1009

It turns it into key/value arguments to the ansible module, causing
hilarious failures.

This can be used to configure wiredTiger's memory usage away from "half
of the RAM on the box".

A sampling of things fixed in 3.0.5 and later.
https://jira.mongodb.org/browse/SERVER-17386
https://jira.mongodb.org/browse/SERVER-19562
https://jira.mongodb.org/browse/SERVER-17424

Explanation: if mongo is set with systemLog.logRotate='reopen', when it
receives a SIGURS1, it'll close and reopen its log file handle.

Changes were originally introduced in 2c53e32c, PR #2217