Tasks for release 2.0.0

[wyardley]

• Mark failing acceptance tests as pending, and re-enable in Travis
• convert parameters to data types - Add Data Types and remove deprecated parameters #406
• Rip out deprecated parameters - Add Data Types and remove deprecated parameters #406
• replace anchor pattern with contain / class ordering
• document parameters with Puppet Strings
• Rip out Mongo 2.x related code
• reformat spec tests to be more readable ?
• Fix acceptance tests

cc @ekohl

[wyardley]

@ekohl let's talk about this some time.
My plan had been to mark the remaining failing acceptance tests as pending so we'd have a baseline and so we avoided merging anything that breaks something new (turns out, we already did that).... but there may be too many failing things for that to be practical, plus the tests are really 2.6 heavy, when we're going to ripping out 2.x anyway.

So I'm thinking we do the minimum needed to get the tests working with 3.4 or a similar version before making too many other changes? I have some minor progress towards that, but it's slow going, and I think we need to have some discussions first about how the repo management piece should work, as well as whether we're making any other changes to the interface of the module (maybe getting rid of mongodb::globals and mongodb::{server,client,...}? not sure if that's too drastic).

[ekohl]

Currently my use case for this module is that Katello uses Pulp which depends on it. The typical deployment is on EL7 and EPEL7 includes MongoDB 2.6.x. That means I wouldn't migrate to the 2.0 version. Given Pulp 3 will drop MongoDB in favor of PostgreSQL it's unlikely we'll ever move to MongoDB 3.

That means I'd highly prefer to get all the fixes in without dropping 2.6 support.

[wyardley]

@ekohl Dropping 2.x support was on the Modules team's roadmap, I think, and it was also of the things Hunner recommended doing first. If we continue to support 2.x, we should maybe rethink how the types / providers should work, or even implement separate ones for 2.x / 3.x? All the spaghetti code needed to make and test the stuff that's different between 2.x and 3.x is pretty messy.

I think one of the recently merged PRs (maybe #393?) already broke some stuff for 2.x, based on my limited playing around with the acceptance tests. I wish we had gotten a better baseline for the acceptance tests earlier on :/

Either way, I think getting rid of anchors and switching to include / contain / etc. as appropriate should get done sooner rather than later.

[ekohl]

How about doing a 2.x release with Puppet 4 types, contain and other basic cleanups and then a 3.x release which drops 2.x? Since we don't need new features but do want to get rid of deprecation warnings, that would work well for us.

[wyardley]

That works for me! We could even keep a 2.x branch for bugfixes.

Do you have time to help with getting acceptance tests working and / or any of the structural work?

[ekohl]

That branch will require some work with the changelogs, but that's a good option. Time is always a limited resource. This week I can't promise anything other than doing my best ot do reviews but when I'm back home I think I can find some time.

[wyardley]

Sounds good, and let's ask around for any other folks who are willing to help.

[ekohl]

#491 is my effort to revisit this. I think it's doable to only drop < 2.6 but keep 2.6 itself supported.