Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ansible-lint doesn't handle module_defaults #2953

Open
Igorgro opened this issue Jan 30, 2023 · 4 comments
Open

Ansible-lint doesn't handle module_defaults #2953

Igorgro opened this issue Jan 30, 2023 · 4 comments
Assignees
Labels
bug feedback-needed Divergent oppinions, additional feedback is desired in order to unblock it.

Comments

@Igorgro
Copy link

Igorgro commented Jan 30, 2023

Summary

Ansible-lint doesn't handle module_defaults and shows warning on every task, where this defaults are missing.

Issue Type
  • Bug Report
OS / ENVIRONMENT
ansible-lint --version
ansible-lint 6.11.1.dev0 using ansible 2.14.1
  • OS: Arch Linux
  • ansible installation method: OS package
  • ansible-lint installation method: OS package
STEPS TO REPRODUCE

Create playbook that uses module_defaults, for example:

- name: Configure mikrotik
  hosts: localhost
  module_defaults:
    community.routeros.api_modify:
      hostname: "10.10.10.1"
      username: "admin"
      password: "admin"
  tasks:
    - name: Get ip
      community.routeros.api: # the warning is showed here
        path: ip address
Desired Behavior

No warning is showed because all required arguments should be taken from module_defaults.

Actual Behavior

The following warning is showed:

WARNING  Listing 1 violation(s) that are fatal
args[module]: missing required arguments: hostname, password, username (warning)
playbook.yml:9 Task/Handler: Get ip

P.S. I think tis is common Ansible issue, because vscode extension and languge server do not handle this also. Should I also open similar issue there?

@Igorgro Igorgro added bug new Triage required labels Jan 30, 2023
@ssbarnea ssbarnea self-assigned this Jan 31, 2023
@ssbarnea ssbarnea added feedback-needed Divergent oppinions, additional feedback is desired in order to unblock it. and removed new Triage required labels Jan 31, 2023
@ssbarnea
Copy link
Member

@Igorgro You are right, we need to do something about it. The big question is how can we distinguish between someone that forgets to add required arguments and someone that uses module _defaults? From the linting perspective is close to impossible to know if module _defaults was defined somewhere outside current file,... that means that when looking at tasks files (included from playbooks or part of roles), we cannot determine if module_defaults were defined or not.

At a single file level as your example, that might be doable, not very easy but possible.

I wonder if defining a module_defaults inside linter configuration could be seen as an acceptable workaround. The values defined there would be used only by the linter.

@cidrblock
Copy link
Contributor

I think the quickest fix for now, while we sort out how to account for the defaults is to allow for a new settings file entry:

agrs_ingore:
- aws\..*
- community\.routeros\..*

It would be a list of regular expressions used to limit the scope of arg checking. Plugin name would be compared against the list and if a match was found we would either not run or not error on missing args.

We should really be accounting for the defaults and using them, but there are a number of places this gets really tricky.

will keep researching to see if ansible-core can help here

@cidrblock
Copy link
Contributor

Just a follow up here, it doesn't appear there is a way for ansible-core to help here as it's syntax check doesn't account for module/group defaults. https://github.com/ansible/ansible/blob/devel/lib/ansible/executor/task_executor.py#L595

I think the best thing to do in the short term is the suggestion above which would allow the user to skip the arg check for certain plugins with the list of regexs.

@cidrblock
Copy link
Contributor

Still working through this one.... more to come

@ssbarnea ssbarnea added this to the external-contributions milestone May 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug feedback-needed Divergent oppinions, additional feedback is desired in order to unblock it.
Projects
Status: No status
Development

No branches or pull requests

3 participants