Require Ansible 2.9.10+ and add deprecation notices to modules

[MarkusTeufelberger]

SUMMARY

We should somehow (ideally in some standard way - galaxy.yml?) require at least Ansible >=2.9.10 so we can add the correct information to module deprecation notices.

ISSUE TYPE

• Feature Idea

COMPONENT NAME

All modules in here

ADDITIONAL INFORMATION

Currently the sanity tests have to include ignores for pylint:ansible-deprecated-no-collection-name - this can be dropped and the necessary info added when we add a requirement for 2.9.10+.

[felixfontein]

True. But we first need to decide which deprecation versions to use, otherwise we cannot do this. For that we need to decide how we want to do some basic versioning / releasing of the collection.

[MarkusTeufelberger]

My suggestion would be eventually releasing a version 1.0.0 with ~the current modules and functionality about the same time as Ansible 2.10 and then moving on towards 2.0.0 where pyopenssl gets dropped. Adding modules or other features would just be a minor version increase (e.g. 1.1.0). I don't see any other major API changes coming up tbh.

Alternatively we could deprecate pyopenssl support by date, but even then we'd need to increment the major version, whatever it is by then.

[MarkusTeufelberger]

Apparently there isn't even a way to show which platforms (e.g. Debian) or Ansible versions (e.g. >=2.10.0) a collection targets: https://docs.ansible.com/ansible/devel/dev_guide/collections_galaxy_meta.html#collections-galaxy-meta

[felixfontein]

For Ansible version, there's an entry in meta/runtime.yml: ansible-collections/community.general@748e40a. No idea whether galaxy shows it though, and which Ansible versions actually understand it.

[felixfontein]

I wrote up #74 as a proposal. I also created a PR which fixes this; I've put in 2.0.0 as the version where things will get removed. So if we're happy with that aspect from #74, we can merge it (and close this issue).