MongoDB 4.2.10 starts to emit warnings about slaveOk() being deprecated, which breaks the module

[dhs-rec]

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 6.18.0
• Distribution: Debian Buster
• Module version: 3.1.0

How to reproduce (e.g Puppet code you use)

Increase MongoDB version from 4.2.9 to 4.2.10.

What are you seeing

Puppet agent runs start failing with an error:

Info: Applying configuration version '1602075392'
Error: Could not prefetch mongodb_database provider 'mongodb': 765: unexpected token at 'WARNING: ) is deprecated and may be removed in the next major release. Please use secondaryOk( instead.

Unfortunately, Puppet cuts off some bits of the message, but I assume the real warning is this:

slaveOk() is deprecated and may be removed in the next major release. Please use secondaryOk() instead.

And indeed, if I change all occurrences of slaveOk() to secondaryOk() it starts working again.

What behaviour did you expect instead

A simple warning shouldn't break the module.

Output log

See above.

[ekohl]

Fixed in #594

[dhs-rec]

Any chance this gets released any time soon?

[antondollmaier]

Any chance this gets released any time soon?

Same here.

Any chance that there might be a release? Is there something stopping a possible release?

[ekohl]

I think mostly that someone has to step up and do the work. Anyone can create a PR with the changelog and bump the version. https://voxpupuli.org/docs/releasing_version/ describes the steps.

[dhs-rec]

I think mostly that someone has to step up and do the work. Anyone can create a PR with the changelog and bump the version. https://voxpupuli.org/docs/releasing_version/ describes the steps.

That's really bad practice, isn't it? This should IMHO be a task for a maintainer of the project, not for the average user.

[ekohl]

Voxpupuli is a collective. To quote voxpupuli.org:

We are a collective of Puppet module, tooling and documentation authors all working together to ensure continued development on the code we maintain.

However, it is volunteer driven. My past few months have been crazy busy so I had no time for it. However, anyone can join the project. We rely on users actually maintaining modules. I've always liked open source because it gave me the ability to fix my own problems. Here it's the same thing: you have a problem and there is a clear opportunity to fix your problem.

[antondollmaier]

I think mostly that someone has to step up and do the work. Anyone can create a PR with the changelog and bump the version. https://voxpupuli.org/docs/releasing_version/ describes the steps.

I can live with this "policy" - I was under the impression that this needs to be done by a maintainer. Let's see ...

[pier4r]

Question: why is it closed?

I understand that we, as community, should fix the issue but the issue in itself is still open right? 3.1.0 has still the problem

(reproduced with puppet 4.10 and CentOS 7.9 . I think also puppet 5.5 has the same problem)

[ekohl]

Issues are closed when it has been fixed in master.

[pier4r]

Ah ok so it is not yet released. Thank you!

[hdep]

Hi,

any change to get this fix released soon ? Last release of the module is 1 year old.
I need this fix because currently the module doesn't works anymore on our mongodb up-to-date nodes.

Thanks you !

[ekohl]

I can only speak for myself, but we just merged the last patches to get rid of MongoDB completely in our infra. That means I no longer have an interest in this module. https://voxpupuli.org/docs/about_vox_pupuli/ isn't very clear on how to join, but I'd encourage anyone who depends on this module to step up and become a maintainer.

[pier4r]

So effectively this module is at the moment without a main maintainer?

[ekohl]

Looking at who merged patches in the past time, I think it's fair to say that this module needs a maintainer. Vox Pupuli is designed as an organization that easily allows a new maintainer to step in though.