1. 25 Jan, 2016 5 commits
    • Upgrades to mongo_replica_set to handle initialization · cda15d39
      Do a bit more error checking before asking for the replica set.
      
      The new mongo play wants to be able to run this against an unconfigured
      Mongo to find out "Do you even have a replica set?" which this can now
      answer (the try/except portion).
      
      In the case where mongo was started without a replSet configured (or
      running getCmdLineOpts fails for an OperationFailure reason), we
      return a dictionary where status is not included to allow tasks to
      detect the failure.  Unfortunately, Ansible doesn't provide an easy way
      to log back why you didn't get a replica set doc.
      
      Documentation improvements for this module
      
      Discusses the return values and some examples of checking them.
      
      Simplify get_replset
      
      If the find_one for a replset fails, just return None.
      We don't need to worry about getting back a dictionary which contains a
      'config' key (presumably this is from an earlier iteration of the code
      which called getReplSetStatus which does act like that).
      
      Rather than raising the exception, use the friendly error here.
      
      I assume the raise/module.fail_json double header was leftover cruft
      from earlier development.
      
      Make the module work without rs being configured
      
      Initially, this module always tried to find and connect to a primary,
      however, during replica set initialization, there is no primary so we
      need to fall back to just connecting to the machine specified.
      
      This is detected by catching the replSetGetStatus failure and falling
      back to the bare get_client method which refactors the connection.
      Kevin Falcone committed
    • OPS-967: Make mongo_3_0 role idempotent · 015b8bce
      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).
      Max Rothman committed
    • Switch to more accurate name · cd42cdf4
      Max Rothman committed
    • Make mongo_rs_member manage whole cluster · b0e95a74
      Now you can provide a (slightly simpler) cluster config and it'll
      idempotently make it so.
      Max Rothman committed
  2. 21 Jan, 2016 3 commits
  3. 20 Jan, 2016 2 commits
  4. 19 Jan, 2016 7 commits
  5. 18 Jan, 2016 1 commit
  6. 15 Jan, 2016 1 commit
  7. 14 Jan, 2016 4 commits
  8. 13 Jan, 2016 14 commits
  9. 12 Jan, 2016 3 commits