Command-line argument --inventory does not work

[LDTips]

When using ansible-runner I wanted to specify alternate inventory directory by using the --inventory commandline argument

However, it does not work as expected. Instead it changes the hosts file in <private_data_dir>/inventory to be equal to the provided

The command I run:
ansible-runner run -p install_sim.yml --inventory /runner/inventory2/ --process-isolation --container-image localhost/ran-deployment-stable .

Results not in using the inventory found in this location, but rather replaces the hosts file contents inside the default folder (/runner/inventory) with the path supplied to the --inventory argument. My hosts file just has the line /runner/inventory2/

If I rearrange the folder structure and use the ansible-playbook install_sim.yml --inventory inventory2, it works as expected

[Shrews]

I believe our handling of --inventory might indeed be broken, but I need to research a bit more.

What version of ansible-runner are you using?

[LDTips]

The version is 2.3.2

[Shrews]

Thanks.

I've dug into this more and it appears that the --inventory value is not being validated properly. The only value that is supported in this CLI parameter is a relative location under the <private_data_dir>/inventory subdirectory. Apparently, it's not designed to support a full path, nor any other value. The inventory parameter to the run() API method is supposed to support multiple types of values, however.

I'll work on getting a fix out for this, as well as improving the documentation around it.

[Shrews]

@LDTips I can only reproduce the behavior you see (contents of inventory/hosts being replaced) when I specify a value for --inventory that does not exist on the localhost. Since you are using /runner in your path, are you attempting to specify the location on the container image (the private data dir is mounted into the container image at that location)? If so, that is not what you should be doing. You should be referencing paths on the localhost.

[LDTips]

I think this occurred even when I was specifying localhost paths, but can't remember it for now. In any case, this behaviour seems weird. You can close this issue for now, as for the time being I am unable to check it due to lack of access to the device on which this bug occurred.

When I have time, I will check it and reopen the issue if even after following your guidelines the issue will still occur.

[Shrews]

Thanks for the response. Going to keep this open as I feel there are improvements to be made wrt the CLI option, at least.