Open russoz opened 2 years ago
Files identified in the description:
If these files are incorrect, please update the component name
section of the description or use the !component
bot command.
cc @abellotti @cben @dkorn @evertmulder @gtanzillo @yaacov @zgalor click here for bot help
Twisting the output of the tests a bit (lousily and lazily so):
$ andebox test -ei -- sanity --docker default --test validate-modules plugins/modules/remote_management/manageiq/manageiq_provider.py \
| grep -oP '\S+ in argument_spec found in \w+' | sed -e "s/'//g" -e 's/ in argument_spec found in /:/g' \
| awk -F: '{ print $2":"$1 }' | sort -u
(...)
alerts:path
alerts:project
alerts:role
alerts:subscription
alerts:uid_ems
metrics:project
metrics:role
metrics:subscription
metrics:uid_ems
provider:path
provider:project
provider:role
provider:subscription
provider:uid_ems
ssh_keypair:certificate_authority
ssh_keypair:password
ssh_keypair:path
ssh_keypair:port
ssh_keypair:project
ssh_keypair:role
ssh_keypair:security_protocol
ssh_keypair:subscription
ssh_keypair:uid_ems
Those are some of the offending pairs options:suboptions
, potentially not for all the 51 errors, but this should cover most of them to get started.
The argument_spec
for these parameters is being built exactly the same in: https://github.com/ansible-collections/community.general/blob/main/plugins/modules/remote_management/manageiq/manageiq_provider.py#L571-L577
def endpoint_list_spec():
return dict(
provider=dict(type='dict', options=endpoint_argument_spec()),
metrics=dict(type='dict', options=endpoint_argument_spec()),
alerts=dict(type='dict', options=endpoint_argument_spec()),
ssh_keypair=dict(type='dict', options=endpoint_argument_spec(), no_log=False),
)
However the docs for each one of the four is completely different: https://github.com/ansible-collections/community.general/blob/main/plugins/modules/remote_management/manageiq/manageiq_provider.py#L69-L186
Condensed version of the docs, showing only the top level option's description and the suboptions:
provider:
description: Default endpoint connection information, required if state is true.
suboptions:
hostname:
port:
userid:
password:
auth_key:
validate_certs:
security_protocol:
certificate_authority:
metrics:
description: Metrics endpoint connection information.
suboptions:
hostname:
port:
userid:
password:
auth_key:
validate_certs:
security_protocol:
certificate_authority:
path:
alerts:
description: Alerts endpoint connection information.
suboptions:
hostname:
port:
userid:
password:
auth_key:
validate_certs:
security_protocol:
certificate_authority:
ssh_keypair:
description: SSH key pair used for SSH connections to all hosts in this provider.
suboptions:
hostname:
userid:
auth_key:
validate_certs:
Given that:
def endpoint_argument_spec():
return dict(
role=dict(),
hostname=dict(required=True),
port=dict(type='int'),
validate_certs=dict(default=True, type='bool', aliases=['verify_ssl']),
certificate_authority=dict(),
security_protocol=dict(
choices=[
'ssl-with-validation',
'ssl-with-validation-custom-ca',
'ssl-without-validation',
'non-ssl',
],
),
userid=dict(),
password=dict(no_log=True),
auth_key=dict(no_log=True),
subscription=dict(no_log=True),
project=dict(),
uid_ems=dict(),
path=dict(),
)
I suppose the problem is that each endpoint in the actual service has a different set of suboptions. The documentation blob could be right, in the sense that it matches the service API, but I cannot find an authoritative reference for these endpoint types (other than looking into ManageIQ code, which I am trying to avoid as my Ruby-fu does not go very far). I mean, I suppose SSL-specific options do not apply to the ssh_keypair
endpoint, but I would feel more comfortable having the actual list so that we can ensure the suboptions provided in the module match the service API.
If this appraisal is right, then it seems to me that we should make four separate versions of the endpoint_argument_spec()
function, one for each endpoint type.
For the record, some docs were found about the API:
But although they thoroughly describe the interface at the providers level, when it comes down to the endpoints parameters, it is vague - it provides "examples", but there is no authoritative description of the parameters.
Another possibility is that the API accepts all the suboptions, but depending on the role (if I got the terminology right), it will use only some of the parameters.
cc @agrare . Yes, different providers take a different set of options, so they are all different. I don't believe we have documentation for each one individually. However, new provider plugins are created somewhat regularly, so would we need to add a new spec here every time?
Either that or we move to a "generic" provider model.
Any chance we can do some gitspelunking on the existing ones? I have tried to do it myself but Ruby was never a forte for me.
Files identified in the description:
If these files are incorrect, please update the component name
section of the description or use the !component
bot command.
Summary
The module
manageiq_provider
has a number of sanity check errors related to undocumented options in the argument spec. This ticket should register the work towards solving them.Issue Type
Bug Report
Component Name
plugins/modules/remote_management/manageiq/manageiq_provider.py
Ansible Version
(but not really relevant to this case)
Community.general Version
main branch (development)
Configuration
(empty)
OS / Environment
Linux Mint (irrelevant to this case)
Steps to Reproduce
Assuming
andebox
is installed:The
-ei
flag will exclude the lines in the sanity ignore files matching the name of the files listed, in this case onlymanageiq_provider.py
.Expected Results
All tests return OK.
Actual Results
Multiple validation errors:
Code of Conduct