actually show plugin config warnings/deprecations

[bcoca]

Now deduped globally

ISSUE TYPE

• Bugfix Pull Request

[bcoca]

cc @briantist

[nitzmahone]

A few suggestions

[bcoca]

did I misread the standard, is alternatives wrong then? or did we just mix both up to the point no one can tell?
I'll take a look at it when I get back, had not meant to resolve the whole issue, I was still mulling on what to do with singular/plural issue.

[bcoca]

@s-hertel updated to accept 'both ways' .. we can punt on standardizing on one or the other for now.

[bcoca]

@briantist @felixfontein , would like to merge this soon, comments?

[felixfontein]

The above does not work. It rejects both alternatives and alternative with errors like extra keys not allowed @ data['deprecated']['alternative'].. Basically doing what you want isn't easily supported with voluptuous (see alecthomas/voluptuous#115), adding your own validator to make sure one of them is there is probably the best (similar to alecthomas/voluptuous#115 (comment)).

Try running this PR against a module that is deprecated (you can find some examples in community.general for example). (Would be good to have a test for that in ansible-core's integration tests for this as well.)

[bcoca]

We had very few deprecation message tests, the file above adds a bunch but i still had some 'todo' cases
https://github.com/ansible/ansible/pull/82593/files#diff-a06276ae256ddf23396903d5813205f1ed799ab8e5f687c5adc87de6a4233863R37

[bcoca]

surprised this does not work, since it took it from the docs example
http://alecthomas.github.io/voluptuous/docs/_build/html/voluptuous.html#module-voluptuous.schema_builder

[felixfontein]

I guess you refer to:

msg = 'Please, use only one type of authentication at the same time.'
schema = Schema({
Exclusive('classic', 'auth', msg=msg):{
    Required('email'): str,
    Required('password'): str
    },
Exclusive('internal', 'auth', msg=msg):{
    Required('secret_key'): str
    },
Exclusive('social', 'auth', msg=msg):{
    Required('social_network'): str,
    Required('token'): str
    }
})

The example shows something else, as you can see from the code fragment which uses it:

with raises(er.MultipleInvalid, "Please, use only one type of authentication at the same time. @ data[<auth>]"):
    schema({'classic': {'email': 'foo@example.com', 'password': 'bar'},
            'social': {'social_network': 'barfoo', 'token': 'tEMp'}})

There you can see that classic and social are sub-dictionaries, and email/password/... are not top-level keys.

[briantist]

would like to merge this soon, comments?

Looked over the code, no specific comments, but very much looking forward to this

[felixfontein]

Since when is deprecated allowed for module option docs? Since this is new and intended, it should be mentioned in the changelog.

(Also schema.py in this PR is still disallowing this for plugin_type == 'module'.)

[bcoca]

They were allowed since deprecations were added for docs, but I don't think it has been used more than 1 or 2 times. I'll update schema too, not sure why that was disabled there, since 'per option deprecation' existed for modules much longer than for plugins.

[bcoca]

most of the time we just used aliases to rename an option and keep old name as alias/backwards compat, I don't think we've removed an option from a module since 1.0

[felixfontein]

Option deprecations for modules were allowed, but documenting them with deprecated never was so far.

most of the time we just used aliases to rename an option and keep old name as alias/backwards compat, I don't think we've removed an option from a module since 1.0

I think this happened quite a lot, especially in collections, but also in ansible/ansible. Actually it even happened in ansible-core: 9f82fc2 Some removals from Ansible 2.9: 808bf02 88f0c85

[bcoca]

Option deprecations for modules were allowed, but documenting them with deprecated never was so far.

It was, for most of Ansible's lifetime there were no restrictions on docs, mostly a few requirements. The core engine still does not implement many restrictions.

The restrictions on docs are a relatively recent development in the 12yr lifetime of the project and part of CI/site docs build, not the runtime.

[felixfontein]

Strict validation of module option docs (which effectively disallowed deprecated in it) was added in 04e816e, which is now there for a bit over 7 years. That's more than half of the 12 years you mentioned.