Try to use replSetGetConfig command before querying system collection and don't care about 'buildIndexes' property.

[llvtt]

Changes:

• Don't wait for buildIndexes property in replica set configuration to match some hard-coded default.
• Try to use replSetGetConfig command first before querying local.system.replset for replica set configuration.

Mongo Orchestration was assuming that buildIndexes was always false. According to the documentation, that may never have been true. Note that MO never actually configured replica sets with buildIndexes: false.

[llvtt]

This fixes MO failures like this one: http://jenkins.bci.10gen.cc:8080/view/Java/job/mongo-java-driver-test/650/jdk=HotSpot5,label=linux64,mongodb_configuration=replica_set,mongodb_option=noauth,mongodb_server=27-nightly/console

This is failing because we're waiting for buildIndexes to be False, which it will never be.

[behackett]

LGTM, though I'm curious why we were checking for buildIndexes in the first place. @jyemin any ideas?

[llvtt]

Discussed this with Spencer to get some extra information:

Starting in 2.7.8, we put all standard options for replica set configurations inside of the replica set configuration document, including buildIndexes. Previously, these options would only appear in the config when set to some non-default value. For buildIndexes, true is the default. Thus, formerly we would only see buildIndexes at all in the config document if it matched Mongo Orchestration's default_params value of false, since that's not the default in the server.

That is why this checking ever worked at all, though it doesn't make any sense. I don't know why MO was ever checking it, much less expecting it to be a value that's not the default when never actually setting it to be that way.

[behackett]

Interesting. Well, ignoring it seems like the right thing to do. Ship it!

[jyemin]

+1