hi @wenottingham , I just ran into #1997 and was wondering if when this feature is implemented it may also delete the no longer used group_vars/all from the inventory if the overwrite flag is set? I found it quite confusing as I had deleted a variable from my group_vars/all which didn't propogate to the inventory. It would be nice to add that feature to this enhancement if possible.

Possibly doable with this, yes.

We also ran into the same problem while refactoring our inventory. It's very confusing and dangerous that deletion of variables in group_vars/all doesn't propagate to the inventory. I suggest to increase priority on this issue.

Echoing what @abedwardsw stated on overwriting the global vars.
At the very least, there could either be:

• an additional checkbox "overwrite global vars"
• simple code change to overwrite global vars if only one inventory source is specified

Adding to @joshmullis checkboxes (for inventory sourced from project)::

• "source group variables from group_vars"
• "source host variables from host_vars"

This would remove the workaround of having an dummy inventory file listing just the groups that should be extended by the projects groupvars:

[webservers]
[databases]
[jumphosts]

Come to think about it, in the dropdown: add the "just source grup_vars" so one doesn't have to use the workaround above at all.

And: adding a priority setting would be nice. So one still can have inventory source 3 overwriting the merged (-i s1 -i s2) sources with a lower priority.

+1

+1

I got a behaviour which seems relevant as well. I'm creating about 10 azurerm inventory sources in the same inventory with some conditional groups which will create me one group per OS type (windows/linux). In the windows one, I put the relevant winrm variables to allow the connections to windows host work from the same templates as linux. This inventory typically syncs on each job execution

Randomly, these variables are wiped. I don't know how or why exactly, as I haven't managed to replicate it. But I will notice it when my jobs against windows hosts start failing because they're trying to ssh to them.

I opened a case with RH which redirected me to this issue.