Switch from digital_ocean module to digital_ocean_droplet

Issue Type

• Feature request

Summary

Deprecations to the digital_ocean module in by ansible 2.8 have broken an import in functional tests and potentially change what dependencies are required based on the version of ansible being used.

Background

• A new module was introduced in Ansible 2.8 for interacting with digitalocean: https://docs.ansible.com/ansible/2.8/modules/digital_ocean_droplet_module.html
• The addition of this module deprecates the existing digital_ocean module: https://docs.ansible.com/ansible/2.8/modules/digital_ocean_module.html#deprecated
• The new digital_ocean_droplet module no longer requires the dopy module to be installed to interact with digitalocean.
• As part of the deprecation, the digital_ocean python module was renamed to _digital_ocean, which breaks the existing import that molecule currently uses to determine if digitalocean support is available: https://github.com/ansible/molecule/blob/86d98ed594029441327c7282208a098ed185076c/test/functional/conftest.py#L356-L362
• The digitalocean module is used in the cookiecutter create and destroy playbooks for the digitalocean driver, as well as in the test playbooks.

Molecule should, of course, stop using the deprecated module in favor of the new module added in ansible 2.8. Doing so introduces some complexity, which is that molecule will now need to inspect the ansible version to conditionally decide which module to use, both in playbooks that use the digitalocean modules, and in the supports_digitalocean function above. There are a few different ways that molecule can deal with this complexity, which I’ve tried to outline here.

Options

1. Fix the broken import, continue using the deprecated module until ansible 2.10 comes out, at which point ansible <2.8 will no longer be supported and we can switch from the deprecated digital_ocean module, which will be removed in ansible 2.12 (so we’ll be able to safely transition during the ansible 2.10 and 2.11 releases. This is a simple option, but is not very user-friendly since it requires ansible 2.8 users to install a dependency to use digitialocean that is no longer required in ansible 2.8.
2. Fix the broken import, conditionally use the correct module based on which version of ansible is currently being used. This is less simple, but means that users should no longer have to install the dopy module for ansible >= 2.8. It will result in more complicated create.yml and destroy.yml playbooks for digitalocean scenarios.
3. Fix the broken import, conditionally use a different cookiecutter template based on the version of ansible installed when the cookiecutter template is used to initialize a scenario. This is the opposite of simple, and while it is an option I don’t think it’s a very good one.
4. Other options welcome. 😃

[bmildren]

Apologies, I lost track of this one - I’ll take a look this week

[decentral1se]

Bump @bmildren @seandst 🦈 🦈 🦈