[DISCUSSION] Thinking of a re-write

[mzupan]

I'm having big issues merging the incoming PRs that deal with mongo v2 and v3 issues.

The big issue is I created this and it was fairly simple and a lot of people have added on to it and there was no tests to make sure functions worked as expected.

I'd like to re-write this plugin from the ground up with proper tests in place.. anyone have any thoughts or if they'd like to join in.

I've never attempted to mock anything like mongo so I'd have to learn where to start on that and which test framework to use.

[warrenpnz]

Could do. I have noticed a number of incompatibilities between the module as it stands and Mongo 3 with WiredTiger, so have been modifying my fork to handle some of these.

With the rewrite, what facility would there be for feature discussions within the community?

test-wise I'm just using Vagrant/Virtualbox images to create clusters and do testing that way, so I guess it depends on what kind of load tests are required as to whether this will stretch resources too much.

[mzupan]

@warrenpnz I use to test in vagrant but it becomes a real mess when people have different setups and time consuming when some use replication and others dont. Some have arbiters and others dont.

I'm really talking about mocking the output of pymongo so you have text files of expected results and it runs the check and compares the results to what the expected results for that input should be

[thias]

It seems like a great idea. I have been working on integrating this check into my puppet nagios module, and it's been complicated. I would love to see nicer failures messages when there are pymongo problems, or mongodb mismatches (I personally use MongoDB 3 with WiredTiger and the MongoDB 2 and mmapv1 checks error out in many different ways).

I would also love to see more automatic choices by default, such as not needing to specify the replicaset (#135), and being able to check all collections in the same way all databases may already be checked (I still need to test that).

(nitpicking : lowercase -w and -c parameters as requested in #120 please! ;-))

[JonathanHuot]

@mzupan, Python library "mock" is easy to do that. I'm using it to mock an http server but it could be the same for a mocked mongodb2.x and a mocked mongodb3.x
Unit tests could be done that way, while integration testing could still be done with Vagrant/Docker.

[dmsquires]

Upgrading to Mongo 3.2 from 2.4 and I'm seeing enough issues to warrant a refresh as well.

If done so, it would be nice if Python3 compliance was kept in mind, and maybe not even worry about MongoDB 2.X compatibility in the rewrite. Eg let MongoDB 2.X support slowly die in the original script.