Skip to content

Allow to reject (or warn) about extra values in AnsiblePlugin.set_options()'s direct parameter #86963

@felixfontein

Description

@felixfontein

Summary

One long-standing and common problem of all lookup and inventory plugins is that if you provide an unknown option to the lookup call or inventory config file, it is simply ignored without any feedback. If a user makes a typo, or misunderstands parameter names like _terms in lookup documentation, there is no warning at all about this. Ansible should error out on superfluous parameters, or at least warn about them.

To avoid breaking backwards compatibility, this should be something that plugins explicitly request (even though I believe that 99.9% of all lookup and inventory plugins want a warning or error), as some lookups or inventory plugins require the current behavior to interpret arbitrary non-documented parameters. I think that plugins should also be able to chose between warnings and errors (they could start with warnings, and make them errors in the next major release of the collection, since suddenly starting to error out would be a breaking change).

I can think of two ways to implement this:

  1. Add a new optional argument (with default "ignore") to AnsiblePlugin.set_options() and _BaseInventoryPlugin._read_config_data() that allows to configure this behavior. The downside is that this is harder to use when you also have to also support older ansible-core versions. You would need a try/except with TypeErrors to handle ansible-core versions knowing about this parameter or not, or compare ansible.__version__ to some value.
  2. Add a new class variable that can be set by plugins to warning/error. Older ansible-core versions would ignore this, and newer ones can use it.

Would something like this be acceptable?

Issue Type

Feature Idea

Component Name

config manager

Additional Information

/

Code of Conduct

  • I agree to follow the Ansible Code of Conduct

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3Priority 3 - Approved, No Time LimitationfeatureThis issue/PR relates to a feature request.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions