Ansible is a radically simple IT automation platform that makes your applications and systems easier to deploy and maintain. Automate everything from code deployment to network configuration to cloud management, in a language that approaches plain English, using SSH, with no agents to install on remote systems. https://docs.ansible.com.

SUMMARY

Launch module.fail_json when a bad escape is used as suggested by Sivel My first attemps of contribution, if I did anything wrong, I'm sorry in advance, just tell and I'll correct

ISSUE TYPE

• Bugfix Pull Request

COMPONENT NAME

replace

ADDITIONAL INFORMATION

Reused test playbook from a-mastermov :

- name: Test replace module error
  hosts: localhost
  gather_facts: no

  tasks:
    - name: Test replace with bad escape
      replace:
        path: /dev/null
        after: ^
        before: $
        regexp: \.
        replace: '\D'

Run ansible-playbook : ansible-playbook replace.yml

Before change

[WARNING]: You are running the development version of Ansible. You should only run Ansible from "devel" if you are modifying the Ansible engine, or trying out features under development. This is a rapidly changing source of code and can
become unstable at any point.
[WARNING]: No inventory was parsed, only implicit localhost is available
[WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'

PLAY [Test replace module error] *************************************************************************************************************************************************************************************************************

TASK [Test replace with bad escape] **********************************************************************************************************************************************************************************************************
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: re.error: bad escape \D at position 0
fatal: [localhost]: FAILED! => {"changed": false, "module_stderr": "Traceback (most recent call last):\n  File \"/home/rperso/.ansible/tmp/ansible-tmp-1672693525.1035416-14540-219985575953942/AnsiballZ_replace.py\", line 107, in <module>\n    _ansiballz_main()\n  File \"/home/rperso/.ansible/tmp/ansible-tmp-1672693525.1035416-14540-219985575953942/AnsiballZ_replace.py\", line 99, in _ansiballz_main\n    invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS)\n  File \"/home/rperso/.ansible/tmp/ansible-tmp-1672693525.1035416-14540-219985575953942/AnsiballZ_replace.py\", line 47, in invoke_module\n    runpy.run_module(mod_name='ansible.modules.replace', init_globals=dict(_module_fqn='ansible.modules.replace', _modlib_path=modlib_path),\n  File \"<frozen runpy>\", line 226, in run_module\n  File \"<frozen runpy>\", line 98, in _run_module_code\n  File \"<frozen runpy>\", line 88, in _run_code\n  File \"/tmp/ansible_replace_payload_amppazku/ansible_replace_payload.zip/ansible/modules/replace.py\", line 317, in <module>\n  File \"/tmp/ansible_replace_payload_amppazku/ansible_replace_payload.zip/ansible/modules/replace.py\", line 287, in main\n  File \"/usr/lib64/python3.11/re/__init__.py\", line 196, in subn\n    return _compile(pattern, flags).subn(repl, string, count)\n           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n  File \"/usr/lib64/python3.11/re/__init__.py\", line 317, in _subx\n    template = _compile_repl(template, pattern)\n               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n  File \"/usr/lib64/python3.11/re/__init__.py\", line 308, in _compile_repl\n    return _parser.parse_template(repl, pattern)\n           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n  File \"/usr/lib64/python3.11/re/_parser.py\", line 1078, in parse_template\n    raise s.error('bad escape %s' % this, len(this)) from None\nre.error: bad escape \\D at position 0\n", "module_stdout": "", "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", "rc": 1}

PLAY RECAP ***********************************************************************************************************************************************************************************************************************************
localhost                  : ok=0    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0   

After change

[WARNING]: You are running the development version of Ansible. You should only run Ansible from "devel" if you are modifying the Ansible engine, or trying out features under development. This is a rapidly changing source of code and can
become unstable at any point.
[WARNING]: No inventory was parsed, only implicit localhost is available
[WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'

PLAY [Test replace module error] *************************************************************************************************************************************************************************************************************

TASK [Test replace with bad escape] **********************************************************************************************************************************************************************************************************
fatal: [localhost]: FAILED! => {"changed": false, "msg": "bad escape \\D at position 0"}

PLAY RECAP ***********************************************************************************************************************************************************************************************************************************
localhost                  : ok=0    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0   

Summary

I have noticed that pylint (ansible-test sanity) marks as a disallowed name a single underscore. Using a single underscore for a variable that is not used is a widely code convention. Is this a bug or intended?

Example:

import asyncio

proc = await asyncio.subprocess.create_subprocess_shell("echo hello", stdout=asyncio.subprocess.PIPE, stderr=asyncio.subprocess.PIPE)
await proc.wait()
if proc.returncode != 0:
    _, stderr = await proc.communicate()
    print(f"ERROR: {stderr}")

Issue Type

Bug Report

Component Name

ansible-test

Ansible Version

core 2.13.5

Configuration

default

OS / Environment

any

Steps to Reproduce

run ansible-test sanity against this code:

import asyncio

proc = await asyncio.subprocess.create_subprocess_shell("echo hello", stdout=asyncio.subprocess.PIPE, stderr=asyncio.subprocess.PIPE)
await proc.wait()
if proc.returncode != 0:
    _, stderr = await proc.communicate()
    print(f"ERROR: {stderr}")

Expected Results

No errors

Actual Results

ERROR: Found 1 pylint issue(s) which need to be resolved:
ERROR: example.py: disallowed-name: Disallowed name "_"

Code of Conduct

• [X] I agree to follow the Ansible Code of Conduct

Summary

Summary

Getting started documentation is difficult to find from the landing page if you don't know the proper terms of what you should be looking for.

Consider use case:

"I have heard what Ansible can do but don't know how to use it or how to get started with it. I have some hosting experience, so I know the best approach is the official documentation even thought there are plenty of third party tutorials."

What happens currently:

When someone lands on https://docs.ansible.com/index.html they are greeted with three main "cards" on the usual focus area where the main content usually appears. All of the three options are equally colored suggesting equal importance and they are titled with technical terms that only an experienced Ansible proressional would know the meaning of in Ansible's case.

In this case the user should know to click the first card titled Ansible Community, but unless they bother to read the description the initial impression is that this link is going to redirect them to some sort of an forum - or a community version of Ansible whatever that is, since the use case does not yet know that.

And even if they read the description they will still be confused between the first and second card since the second option sounds like it's going to give a overall picture of an ecosystem where all features of Ansible are used.

There is a card with higher visual importance and that's going to redirect the newcomer to even more choices and possibly entirely off docs.ansible.com

I did share similar use case as my example one (with the exception that I was applying for a job with Ansible in requirements), now I have used Ansible for quite much longer and in my current docs use case I know somewhat okay what those terms on the landing page mean and I am somewhat quickly able to find the correct section of the documentation, so I don't need to visit the landing page.

I think the primary function of an landing page in documentation should be to guide the novice user getting started with the documented thing in question

Suggested action for improvement

Improve discoverability of the getting started guide by adding "Get started with Ansible" card to the landing page of docs.ansible.com with a link to this page: https://docs.ansible.com/ansible/latest/getting_started/index.html . The card should have high priority in the visual hierarchy to act as the "call to action".

Issue Type

Documentation Report

Component Name

unknown

Ansible Version

ansible [core 2.14.1]
  config file = None
  configured module search path = ['/not-applicable']
  ansible python module location = /not-applicable
  ansible collection location = /not-applicable
  executable location = /not-applicable
  python version = 3.10.9 (main, Dec  7 2022, 00:00:00) [GCC 12.2.1 20221121 (Red Hat 12.2.1-4)] (/usr/bin/python3)
  jinja version = 3.1.2
  libyaml = True

Configuration

CONFIG_FILE() = None

OS / Environment

Browser (any)

Additional Information

In summary

Code of Conduct

• [X] I agree to follow the Ansible Code of Conduct

SUMMARY

This turns the systemd module's daemon_reload and daemon_reexec commands into no-ops when the target is a chroot.

This is needed as the chroot doesn't run systemd, which will make any module invocation containing one of those two commands fail with something like "systemd isn't active". This is what you get without this PR.

ISSUE TYPE

• Bugfix Pull Request

COMPONENT NAME

systemd module

ADDITIONAL INFORMATION

The patch assumes that if the target is a chroot, it doesn't run systemd. I'm not sure if this is always the case; there might be people out there that somehow run systemd in a chroot, if this is at all possible/feasible. For those people, daemon_reload and daemon_reexec would work properly without this PR, and do nothing with the PR. So a cleaner solution that would cover this case might be to actually detect a running/active systemd rather than a chroot. Still, without this PR, the much more common case of someone trying to run systemd daemon_reload against a chroot will fail, which seems to be the more severe problem for me (my use case was https://github.com/multi-io/armbox, which uses Armbian to debootstrap a Debian system for ARM boards in a chroot, then uses Ansible to provision it).

Closes #79639

SUMMARY

This pull request fixes #79639 by re ordering chdir in codes

ISSUE TYPE

• Bugfix Pull Request

COMPONENT NAME

except.py from lib/ansible/modules/expect.py

SUMMARY

Fix Typo in Arch Linux name

ISSUE TYPE

• Docs Pull Request

+label: docsite_pr

SUMMARY

ISSUE TYPE

• Bugfix Pull Request
• Docs Pull Request
• Feature Pull Request
• Test Pull Request

COMPONENT NAME

ADDITIONAL INFORMATION