Add options for parsing Ansible dynamic inventory

[PhillSimonds]

Problem Overview

Schema-enforcer currently creates Ansible inventory by instantiating a custom AnsibleInventory class. This class glues some ansible built-in classes and some custom methods together to create the inventory and run schema validation tests against it.

The AnsibleInventory class's methods for constructing inventory, passes whatever is configured as the value of config.SETTINGS.ansible_inventory in as the ansible built-in ansible.inventory.manager.InventoryManager's sources argument when it is called by cli.py. Currently, the only supported value which can be passed into this argument is an inventory file declaration. We've tested passing an inventory directory in as well as a dynamic inventory script without issue, but we had to specify ansible-specific environment variables to do so.

This issue has been opened so that we can discuss a strategy for parsing dynamic inventory.

My Thoughts:

I believe a few options exist:

1) Allow the user to pass an ansible.cfg file in -- this would be declared as a variable in the pyproject.toml file. E.g.

bash$ cat pyproject.toml
[tool.schema_enforcer]
 ansible_config_file = "ansible.cfg"

2) Set dynamic inventory settings directly in the pyproject.toml file. E.g.

bash$ cat pyproject.toml
[tool.schema_enforcer]
ansible_enable_plugins = ["host_list", "script", "auto", "yaml", "ini", "toml"]
ansible_inventory_script_dir = "inventory"

3) Infer settings directly from environment variables and don't worry about allowing the user to configure these in a config file.

If we go with option 1, I believe we may lack full coverage of user-expected configuration settings which could cause frustration for the users. If we go with option 2, we'll end up replicating a lot of what ansible can already define in an ansible.cfg file. If we go with option 3, configuration settings become a bit obscure.

[ryanmerolle]

Any thoughts on the approach here? I feel like option 1 makes things easier to get going without much settings, but could lack full coverage of user expected config as you mentioned. Option 2 seems to fit with the current model.

I say you avoid option 3.

I am super excited to leverage this with the netbox inventory plugin, but I think it may be useful to give an example of how to run schemea enforcer on the hostvars created by dynamic plugins. For people using config_context in netbox (flattened or not), where should they define the schemas to use? For example I think I would define schema mapping in my platform associated config_context or role associated config_context.

[PhillSimonds]

I agree -- I like option 2, it maps features supported by schema-enforcer declaratively rather than leaving the user guessing.

I'll throw a PR together on this and include some examples including dynamic inventory from netbox! :)