mongodump 3.5.x incompatible with mongodb 3.6.x

[russt]

Running mgob against current stable/mongodb chart results in immediate falure after connection to remote database.

Tracked it down the admin.system.keys collection which cannot be dumped. I believe that this collection holds keys for the replication set. It cannot be accessed even from root user within the local mongo client.

See: https://jira.mongodb.org/browse/TOOLS-1797

bash-4.3# mongodump --version
mongodump version: v3.5.0-4965-g6c9498c36b

bash-4.3# mongodump -h mongo-mongodb-primary-0.mongo-mongodb-headless.default.svc.cluster.local -u root  --authenticationDatabase=admin -d admin
Enter password:

2018-07-26T23:52:01.769+0000	Failed: error counting admin.system.keys: not authorized on admin to execute command { count: "system.keys", query: {}, $readPreference: { mode: "secondaryPreferred" }, $db: "admin" }
bash-4.3# mongodump -h mongo-mongodb-primary-0.mongo-mongodb-headless.default.svc.cluster.local -u root  --authenticationDatabase=admin -d local
Enter password:

2018-07-26T23:52:29.369+0000	writing local.oplog.rs to 
2018-07-26T23:52:29.369+0000	writing local.startup_log to 
2018-07-26T23:52:29.369+0000	writing local.me to 
2018-07-26T23:52:29.369+0000	writing local.replset.minvalid to 
2018-07-26T23:52:29.386+0000	done dumping local.startup_log (3 documents)
2018-07-26T23:52:29.386+0000	writing local.replset.election to 
2018-07-26T23:52:29.388+0000	done dumping local.replset.election (1 document)
2018-07-26T23:52:29.389+0000	writing local.replset.oplogTruncateAfterPoint to 
2018-07-26T23:52:29.389+0000	done dumping local.me (1 document)
2018-07-26T23:52:29.390+0000	done dumping local.replset.oplogTruncateAfterPoint (1 document)
2018-07-26T23:52:29.393+0000	done dumping local.replset.minvalid (1 document)
2018-07-26T23:52:29.538+0000	done dumping local.oplog.rs (27764 documents)

When we dump directly in the mongodb container, works fine:

root@mongo-mongodb-primary-0:/# mongodump --version
mongodump version: r3.6.6
...
root@mongo-mongodb-primary-0:/# cd /tmp
root@mongo-mongodb-primary-0:/tmp# mongodump -u root -d admin
Enter password:

2018-07-27T00:01:25.996+0000	writing admin.system.users to 
2018-07-27T00:01:25.998+0000	done dumping admin.system.users (3 documents)
2018-07-27T00:01:25.998+0000	writing admin.system.version to 
2018-07-27T00:01:26.000+0000	done dumping admin.system.version (2 documents)
2018-07-27T00:01:26.000+0000	writing admin.movie to 
2018-07-27T00:01:26.002+0000	done dumping admin.movie (2 documents)

Suggest that mgob be updated to play with stable/mongodb chart or branched to support different releases.

[stefanprodan]

Hi @russt can you try stefanprodan/mgob:0.10 should work with MongoDB 3.6

[russt]

Hi @stefanprodan confirmed configuration with 0.10. Had much trouble getting it to work on minikube, but that's another story.. (bottom line, mgob requires k8s 1.10 to avoid ConfigMap mount bug).

[stefanprodan]

The ConfigMap volume mount bug fix was backported into 1.9 but maybe Minikube didn't pick that up. Thanks for testing it.

[russt]

I was using minikube 0.25.2 which included k8s 1.9.4 and hit the bug. I was finally able to install minikube 0.28.2 using this work-around to avoid startup hang:

minikube start --bootstrapper=localkube --vm-driver=vmwarefusion

Once I was able to upgrade, I was able to configure mgob.
Ref: kubernetes/minikube#2791