Small Update in developing_plugins.rst for Inventory Plugins #2746
Conversation
I could not find the `_read_config_file()` in the official ansible repo. the `_read_config_data()` is used in the default inventory-plugins like auto, constructed etc. though. Also I'd propose to explain the difference between `_read_config_file()` and `get_option` and add that they are not mutually exclusive.
ansible-documentation-bot
bot
added
the
new_contributor
|
Thanks for your Ansible docs contribution! We talk about Ansible documentation on Matrix at #docs:ansible.im if you ever want to join us and chat about the docs! We meet on Matrix every Tuesday. See the Ansible calendar for meeting details. We welcome additions to our weekly agenda items too. You can add the |
| @@ -80,7 +80,7 @@ Some plugin types handle this differently: | |||
|
|
|||
| * Become, callback, connection and shell plugins are guaranteed to have the engine call ``set_options()``. | |||
| * Lookup plugins always require you to handle it in the ``run()`` method. | |||
| * Inventory plugins are done automatically if you use the ``base _read_config_file()`` method. If not, you must use ``self.get_option(<option_name>)``. | |||
| * Inventory plugins are done automatically if you use the ``_read_config_data()`` method. If not, you must use ``self.get_option(<option_name>)``. | |||
| * Cache plugins do it on load. | |||
| * Cliconf, httpapi and netconf plugins indirectly piggy back on connection plugins. | |||
| * Vars plugin settings are populated when first accessed (using the ``self.get_option()`` or ``self.get_options()`` method. | |||
There was a problem hiding this comment.
| * Vars plugin settings are populated when first accessed (using the ``self.get_option()`` or ``self.get_options()`` method. | |
| * Vars plugin settings are populated when first accessed (using the ``self.get_option()`` or ``self.get_options()`` method). |
There was a problem hiding this comment.
Missing round bracket. Rest LGTM. cc @bcoca
There was a problem hiding this comment.
I think the important difference between _read_config_data() and get_option() is that former is used to load the configdata from the .yaml which was used to call the plugin but also goes through all the options from the DOCUMENTATION-block. Latter tries to get the options via self._options (which is defined if u call the _read_config_data() before) and if not uses the same function to try and get the options on a different way.
There was a problem hiding this comment.
The original phrase it was meant to say if not use the set_options() method, as some plugins do not have a 'common inventory YAML configuration file'
There was a problem hiding this comment.
In both cases you still use get_option(s) to retrieve the configuration settings, the line was supposed to show how the plugin sets them.
There was a problem hiding this comment.
In both cases you still use
get_option(s)to retrieve the configuration settings, the line was supposed to show how the plugin sets them.
Yes that's true. I think I'd prefer a precise description in the documentation of the use cases of each function :)
I could not find the
_read_config_file()in the official ansible repo. the_read_config_data()is used in the default inventory-plugins like auto, constructed etc. though. Also I'd propose to explain the difference between_read_config_file()andget_optionand add that they are not mutually exclusive.