-
Rafael Guterres Jeffman authored
This patch add several deprecate warnings to FreeIPABaseModule, and creates adapters to ease conversion of client classes to IPAAnsibleModule. There is no 'ipa_commands' management in IPAAnsibleModule, as 'command's is a list of tuples containing '(command, name, args)', and should be managed by the module itself. Commands with no arguments should use an empty dictionary as 'args'. The 'ipa_run' method should be replaced by: ``` exit_args = {} ipaapi_context = self.params_get("ipaapi_context") with self.ipa_connect(context=ipaapi_context): self.check_ipa_params() self.define_ipa_commands() changed = self.execute_ipa_commands( self.ipa_commands, result_handler=my_custom_handler, exit_args=exit_args ) self.exit_json(changed=changed, **exit_args) ``` The 'process_command_result' method should be changed to a result handler: ``` def my_result_handler(self, result, command, name, args, exit_args): """Process command result.""' ``` Use of 'ipa_params' should be replaced by IPAAnsibleModule.params_get. If 'get_ipa_command_args' is used, then the mapping can be created with class IPAParamMapping (formelly AnsibleFreeIPAParams), which also enables the same property-like usage of 'ipa_params': ``` param_mapping = IPAParamMapping(module, mapping) ``` The goal is to have all ansible-freeipa modules using the same codebase, reducing code duplication, and allowing better object composition, for example, with the IPAParamMapping class.Rafael Guterres Jeffman authoredThis patch add several deprecate warnings to FreeIPABaseModule, and creates adapters to ease conversion of client classes to IPAAnsibleModule. There is no 'ipa_commands' management in IPAAnsibleModule, as 'command's is a list of tuples containing '(command, name, args)', and should be managed by the module itself. Commands with no arguments should use an empty dictionary as 'args'. The 'ipa_run' method should be replaced by: ``` exit_args = {} ipaapi_context = self.params_get("ipaapi_context") with self.ipa_connect(context=ipaapi_context): self.check_ipa_params() self.define_ipa_commands() changed = self.execute_ipa_commands( self.ipa_commands, result_handler=my_custom_handler, exit_args=exit_args ) self.exit_json(changed=changed, **exit_args) ``` The 'process_command_result' method should be changed to a result handler: ``` def my_result_handler(self, result, command, name, args, exit_args): """Process command result.""' ``` Use of 'ipa_params' should be replaced by IPAAnsibleModule.params_get. If 'get_ipa_command_args' is used, then the mapping can be created with class IPAParamMapping (formelly AnsibleFreeIPAParams), which also enables the same property-like usage of 'ipa_params': ``` param_mapping = IPAParamMapping(module, mapping) ``` The goal is to have all ansible-freeipa modules using the same codebase, reducing code duplication, and allowing better object composition, for example, with the IPAParamMapping class.
Writing a new Ansible FreeIPA module
A ansible-freeipa module should have:
-
Code:
- A module file placed in
plugins/modules/<ipa_module_name>.py
- A module file placed in
-
Documentation:
-
README-<module_name>.mdfile in the root directory and linked from the main README.md - Example playbooks in
playbooks/<module_name>/directory
-
-
Tests:
- Test cases (also playbooks) defined in
tests/<module_name>/test_<something>.yml. It's ok to have multiple files in this directory.
- Test cases (also playbooks) defined in
Use the script utils/new_module to create the stub files for a new module.