Fix service_mgr fact collection

[alikins]

The platform/distro/etc facts were being passed in
correctly, but service_mgr.py was looking up the
wrong names ('system' vs 'ansible_system')

Fixes #30753, #31095

SUMMARY

ISSUE TYPE

• Bugfix Pull Request

COMPONENT NAME

lib/ansible/module_utils/facts/system/service_mgr.py

ANSIBLE VERSION

ansible 2.5.0 (service_mgr_fact_30753 62d0f6c8c8) last updated 2017/10/24 12:04:28 (GMT -400)
  config file = /home/adrian/src/ansible/ansible.cfg
  configured module search path = [u'/home/adrian/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /home/adrian/src/ansible/lib/ansible
  executable location = /home/adrian/src/ansible/bin/ansible
  python version = 2.7.13 (default, May 10 2017, 20:04:28) [GCC 6.3.1 20161221 (Red Hat 6.3.1-1)]

ADDITIONAL INFORMATION

[toke]

@alikins Thanks a lot for your effort.
This fixes the issue. Let's hope it will make it in 2.4.1.

[abadger]

Cherry-picked for the 2.4.2beta1 release. I'll cut that tarball later this week.

[aabdnn]

I've downloaded and installed ansible-2.4.2.0-0.1.beta1.tar.gz. However, it's still not working correctly:

% ansible --version                                                 
ansible 2.4.2.0
  config file = None
  configured module search path = [u'/Users/anandb/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/local/lib/python2.7/site-packages/ansible
  executable location = /usr/local/bin/ansible
  python version = 2.7.14 (default, Sep 25 2017, 09:53:22) [GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.37)]
% ansible centos6host -bK -m setup -a filter=ansible_service_mgr
SUDO password: 
centos6host | SUCCESS => {
    "ansible_facts": {
        "ansible_service_mgr": "service"
    }
}

[toke]

@aabdnn I can't confirm your observation.
Is it a centos 6 system?

I've tested ansible tags v2.3.2.0-1 vs v2.4.2.0-0.1.beta1
using the vagrant images debian/wheezy64 and centos/6.

I used this snippets for the centos test (replaced the image):
https://gist.github.com/toke/d5de03c70c9c7f1a2ec6acd7a9e3753a

Wheezy tests also ran against real hosts previously affected.

[aabdnn]

Yes, it's definitely a CentOS 6 system:

% ansible centos6host -a 'cat /etc/redhat-release'              
centos6host | SUCCESS | rc=0 >>
CentOS release 6.9 (Final)

[toke]

Still having trouble reproducing...

TASK [vars] ********************************************************************
ok: [default] => {
    "msg": "Ansible: 2.4.2.0\nOS: CentOS 6.9 Final\nService_mgr: upstart\n"
}

using this playbook

---

- hosts: all
  tasks:
    - name: vars
      debug:
        msg: |
          Ansible: {{ ansible_version.full }}
          OS: {{ ansible_distribution }} {{ ansible_distribution_version }} {{ ansible_distribution_release }}
          Service_mgr: {{ ansible_service_mgr }}

looks as expected.

[aabdnn]

Okay, so the playbook works, and reports "upstart" for the service manager:

% ansible-playbook debug_setup.yml -bK -l centos6host
SUDO password: 

PLAY [all] *****************************************************************************************************************************************************

TASK [Gathering Facts] *****************************************************************************************************************************************
ok: [centos6host]

TASK [vars] ****************************************************************************************************************************************************
ok: [centos6host] => {
    "msg": "Ansible: 2.4.2.0\nOS: CentOS 6.9 Final\nService_mgr: upstart\n"
}

PLAY RECAP *****************************************************************************************************************************************************
centos6host            : ok=2    changed=0    unreachable=0    failed=0

However, the following still fails. What is different about them?

% ansible centos6host -bK -m setup -a filter=ansible_service_mgr
SUDO password: 
centos6host | SUCCESS => {
    "ansible_facts": {
        "ansible_service_mgr": "service"
    }
}

[toke]

Fun fact, try ansible centos6host -bK -m setup | grep ansible_service_mgr
WTF?

Actually I don't know what's going on here and not sure it's the same issue.

It seems to be related to the filter implementation in setup module.

[aabdnn]

Whoa! So when the "setup" module runs without any "filter" parameter, it also detects upstart properly, but with "filter=ansible_service_mgr" it fails. So there's still some kind of bug at work.

[abadger]

It looks like the original big has been fixed but they is another one still. Can someone open up a new issue with the details of the new reproducer? @alikins is on vacation today still I want to make sure this information isn't lost.

[toke]

@abadger I've opened #32286 to track this issue.

[alikins]

Fixes #32001