Hello Team,
I just want to know why we have builtin for all modules in ansible earlier it was just module name
Hello Team,
I just want to know why we have builtin for all modules in ansible earlier it was just module name
It is now recommended that all modules be called by their FQCN (fully qualified community name).
These ansible.builtin.file and file are the same, but ansible.builtin.file will always guarantee which file module you mean to reference in case some other community package also has a module named file.
Walter
In FCQN , “builtin” exists for only ansible’s builtin(native) modules .
We have other modules too from community or vendors …
https://docs.ansible.com/ansible/latest/collections/index_module.html
short answer:
Because collections
long answer:
Since we added the 'collections' feature we also introduced
namespaces, including for the modules that existed before collections
(version 2.9), they CAN still use the 'short name' or 'module name' as
you called it, even for modules that were moved to collections, will
still work (as long as the providing collection is installed) with the
short name. So you DO NOT NEED to update your playbooks to work with
newer versions of Ansible, it is just what the updated documentation
and linting tools recommend for new content or when you are updating
existing plays/roles.
To ensure disambiguation the ansible.builtin and ansible.legacy
namespaces were created, the 'builtin' will always select the modules
'shipped' with ansible, while 'legacy' will allow for the overridden
module of same name. For example `ansible.builtin.ping` will always
used the shipped copy, while `ansible.legacy.ping` will use that copy
unless there is another version of the copy module in a play adjacent
`library/` directory (or in role). Using the 'ping' name will work
like if using `ansible.legacy.ping` which is the same as 'pre
collection' behavior.
For modules that used to be in core in <= 2.9, you can still use the
short name as we have a 'redirect file' that will go to the collection
version of the module, ensuring backwards compatibility.
note: what i just wrote for 'modules' applies to all plugin types, it
is just modules are the most commonly used/thought of.
Thanks a lot Brian. Your explanation cleared my views.