Ansible < 2.11 fails on roles that contain argument specification

[tadeboro]

Summary

If the role contains an argument specification, Ansible < 2.11 fails to use it and reports "ERROR! 'argument_specs' is not a valid attribute for a RoleMetadata".

Issue Type

Bug Report

Component Name

include_role

Ansible Version

$ ansible --version
ansible 2.9.18
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/tadej/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.9/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.9.4 (default, Apr  6 2021, 00:00:00) [GCC 10.2.1 20201125 (Red Hat 10.2.1-9)]

Configuration

$ ansible-config dump --only-changed

OS / Environment

Fedora 33

Steps to Reproduce

$ mkdir -p /tmp/cols/ansible_collections/sensu/
$ cd cols/ansible_collections/sensu/
$ git clone --branch role-argspec --depth 1 git@github.com:xlab-steampunk/sensu-go-ansible.git sensu_go
$ cd sensu_go
$ ANSIBLE_COLLECTIONS_PATHS=/tmp/cols ansible -m include_role -a name=sensu.sensu_go.install -vvv localhost

Expected Results

Ansible should ignore the argument_specs and run the role without parameter validation.

Actual Results

ansible 2.9.18
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/tadej/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.9/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.9.4 (default, Apr  6 2021, 00:00:00) [GCC 10.2.1 20201125 (Red Hat 10.2.1-9)]
Using /etc/ansible/ansible.cfg as config file
host_list declined parsing /etc/ansible/hosts as it did not pass its verify_file() method
script declined parsing /etc/ansible/hosts as it did not pass its verify_file() method
auto declined parsing /etc/ansible/hosts as it did not pass its verify_file() method
Parsed /etc/ansible/hosts inventory source with ini plugin
Skipping callback 'actionable', as we already have a stdout callback.
Skipping callback 'counter_enabled', as we already have a stdout callback.
Skipping callback 'debug', as we already have a stdout callback.
Skipping callback 'dense', as we already have a stdout callback.
Skipping callback 'dense', as we already have a stdout callback.
Skipping callback 'full_skip', as we already have a stdout callback.
Skipping callback 'json', as we already have a stdout callback.
Skipping callback 'minimal', as we already have a stdout callback.
Skipping callback 'null', as we already have a stdout callback.
Skipping callback 'oneline', as we already have a stdout callback.
Skipping callback 'selective', as we already have a stdout callback.
Skipping callback 'skippy', as we already have a stdout callback.
Skipping callback 'stderr', as we already have a stdout callback.
Skipping callback 'unixy', as we already have a stdout callback.
Skipping callback 'yaml', as we already have a stdout callback.
META: ran handlers
localhost | SUCCESS => {
    "changed": false,
    "include_args": {
        "name": "sensu.sensu_go.install"
    }
}
ERROR! 'argument_specs' is not a valid attribute for a RoleMetadata

The error appears to be in '/tmp/cols/ansible_collections/sensu/sensu_go/roles/install/meta/main.yml': line 1, column 1, but may
be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:


galaxy_info:
^ here

Code of Conduct

• I agree to follow the Ansible Code of Conduct

[ansibot]

Files identified in the description:

• lib/ansible/playbook/role/include.py

If these files are incorrect, please update the component name section of the description or use the !component bot command.

click here for bot help

[Shrews]

related: PR #73120

[samdoran]

This is definitely an issue. We are discussing how best to address this.

[samdoran]

We discussed this in the Core IRC meeting today and decided on the following:

Role argument specs will move to meta/argument_specs.yml in the next release of Ansible 2.11.

The argument_specs key in meta/main.yml will continue to work but the meta/argument_specs.yml file will be preferred over meta/main.yml.