If you want to contribute a module to Ansible, you must meet our objective and subjective requirements. Please read the details below, and also review our tips for module development.
Modules accepted into the main project repo ship with every Ansible installation. However, contributing to the main project isn’t the only way to distribute a module - you can embed modules in roles on Galaxy or simply share copies of your module code for local use.
To contribute a module to Ansible, you must:
<something>_facts, it should be because its main purpose is returning
ansible_facts. Do not name modules that do not do this with
_facts. Only use
ansible_factsfor information that is specific to the host machine, for example network interfaces and their configuration, which operating system and which programs are installed.
ansible_facts) should be named
_info. General information is non-host specific information, for example information on online/cloud services (you can access different accounts for the same online service from the same host), or information on VMs and containers accessible from the machine.
If your module meets our objective requirements, we’ll review your code to see if we think it’s clear, concise, secure, and maintainable. We’ll consider whether your module provides a good user experience, helpful error messages, reasonable defaults, and more. This process is subjective, and we can’t list exact standards for acceptance. For the best chance of getting your module accepted into the Ansible repo, follow our tips for module development.