Skip to content

Small Update in developing_plugins.rst for Inventory Plugins #2746

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: devel
Choose a base branch
from
Open

Small Update in developing_plugins.rst for Inventory Plugins #2746

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/docsite/rst/dev_guide/developing_plugins.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* 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).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing round bracket. Rest LGTM. cc @bcoca

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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'

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 :)

Expand Down