> That's why I was more leaning towards a form of catch-all key.
I think the main issue with this, as the code stands today, is that many of the
functions that perform the validation compare provided keys to those keys in
the spec to decide whether or not further work is needed (setting defaults
Thanks for the response.
> Adding toggles that change behavior is a pattern I try to avoid
That's why I was more leaning towards a form of catch-all key.
> This would also allow bogus data in, such as key names with typos.
If the role's interface uses a fixed list of keys, and they define the r
Patrick,
Thanks for reaching out on the mailing list. We came across that issue during
our biweekly triage meeting where we don't have time to respond in detail since
we are just trying to evaluate all the issues in the queue.
The first problem with allowing arbitrary keys in the argument spec
So I was eager to try out the new role argument validation which is in the
pipeline for 2.11
(https://docs.ansible.com/ansible/devel/user_guide/playbooks_reuse_roles.html#role-argument-validation),
but immediately ran into an issue, and thought it would be good to discuss.
The issue is the abi
