# Known regression in sysctl module?

**URL:** <https://forum.ansible.com/t/known-regression-in-sysctl-module/14354>\
**Category:** Ansible Developer\
**Created:** [January 15, 2014, 8:38pm UTC](https://forum.ansible.com/t/known-regression-in-sysctl-module/14354 "2014-01-15T20:38:31Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Peter\_Gehres](https://avatars.discourse-cdn.com/v4/letter/p/f17d59/32.png) [@Peter\_Gehres](https://forum.ansible.com/u/Peter_Gehres)\
**Post date:** [January 15, 2014, 8:38pm UTC](https://forum.ansible.com/t/known-regression-in-sysctl-module/14354/1 "2014-01-15T20:38:31Z")

</div>

Was the commit “Fixes #5469 Refactor sysctl module into object oriented code,” ca055844954ac74116b606feee9a1ef498865da0 intended to not be backward compatible?

A git bisect show that the commit broke the following task:

- name: disable ipv6  
sysctl: name=net.ipv6.conf.all.disable\_ipv6 value=1 state=present checks=both  
by removing the “checks” parameter.

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\
**Post date:** [January 15, 2014, 8:50pm UTC](https://forum.ansible.com/t/known-regression-in-sysctl-module/14354/2 "2014-01-15T20:50:38Z")

</div>

“A git bisect show that the commit broke the following task:”

Broke how, exactly?

You’re not showing any output, steps to reproduce, or description of a problem.

---

<div class="post-metadata">

**Author:** ![Peter\_Gehres](https://avatars.discourse-cdn.com/v4/letter/p/f17d59/32.png) [@Peter\_Gehres](https://forum.ansible.com/u/Peter_Gehres)\
**Post date:** [January 15, 2014, 8:56pm UTC](https://forum.ansible.com/t/known-regression-in-sysctl-module/14354/3 "2014-01-15T20:56:29Z")

</div>

TASK: [common | disable ipv6] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*  
failed: [opsawx1.ord.app.dy] =\> {“failed”: true, “item”: “”}  
msg: unsupported parameter for module: checks

FATAL: all hosts have already failed – aborting

Steps to reproduce, try the task I put in the first email. The diff of the “refactor” clearly shows that the “checks” parameter has been removed. Was this intended?

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\
**Post date:** [January 15, 2014, 9:14pm UTC](https://forum.ansible.com/t/known-regression-in-sysctl-module/14354/4 "2014-01-15T21:14:37Z")

</div>

Yes.

Our basic analysis of the sysctl module was that the quality was not quite up to our standards and had some problems in regard to the current value of the sysctl on the system.

As a result, we removed the checks parameter since it was no longer needed.

---

<div class="post-metadata">

**Author:** ![Peter\_Gehres](https://avatars.discourse-cdn.com/v4/letter/p/f17d59/32.png) [@Peter\_Gehres](https://forum.ansible.com/u/Peter_Gehres)\
**Post date:** [January 15, 2014, 9:19pm UTC](https://forum.ansible.com/t/known-regression-in-sysctl-module/14354/5 "2014-01-15T21:19:59Z")

</div>

Thanks. That’s why I asked here before filing a bug 🙂

Would it be too much to ask for a posting to ansible-devel before parameters are removed from modules with explanations behind the reasoning? That way when these things are discovered by those of us testing the bleeding edge we can search the list, see the reason, and fix our playbooks?

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\
**Post date:** [January 15, 2014, 9:22pm UTC](https://forum.ansible.com/t/known-regression-in-sysctl-module/14354/6 "2014-01-15T21:22:27Z")

</div>

Generally we try to. We may miss something from time to time.

The other option would have been to keep it responding to check and completely ignoring and undocumenting the option, which _may_ be the right course of action here, but our view was the option was so very broken we didn’t think it was being utilized.

It appears we were incorrect and stand corrected 🙂