Open lyrandy opened 2 weeks ago
Files identified in the description:
If these files are incorrect, please update the component name
section of the description or use the !component
bot command.
I believe this area can be improved to accommodate.
While doing some more digging, I also found https://github.com/ansible/ansible/issues/17100#issuecomment-504467928 which mentions that there aren't really a hierarchy of groups, since everything eventually renders down to hosts and vars. I think it's still helpful to conceptualize the group hierarchy to rationalize how variables will eventually "settle", so to speak.
As mentioned in the PR: this is not a bug, but a feature request.
Thank you for having a look at the PR and providing feedback. I'll address the CI and then make the recommended changes. I'm not too certain how to change the label from bug
to feature
, do I need to open a new issue?
For my own understanding, how are undocumented behaviours treated when it comes to making modifications to them? In my case, I did not notice any mention of how it integrates with VirtualBox groups, just the usual groups
and keyed_groups
keywords I've seen in basically all other dynamic inventory plugins. Is the approach to treat changes to the behaviour as a new feature until it is formally documented, after which it becomes more obvious to triage?
Also, breaking changes understandably must have sufficient communication and lead time for consumers to prepare for the change. How does it work to schedule the release of the breaking change? I only know that it will usually be included in major version updates, but I am curious about the other logistics before the release (like from when a PR is raised, how is it communicated, etc)
I am new to the scene so I appreciate your help and guidance regarding processes and workflows :)
Summary
My usage of Ansible takes advantage of Ansible's nested groups for variable management. I make heavy use of Vagrant + VirtualBox to speed up local development and testing of Ansible code.
The way the dynamic inventory assigns groups currently does not match the VirtualBox documentation. According to the documentation, you can assign a VM with multiple groups by delimiting it with a comma
,
character, and nest groups using the slash/
character.Ultimately, the objective is to be able to harmonize the way groups are set up with VirtualBox and with Ansible. It appears the concept of nested (or parent-child) groups match, so it should align.
See: https://www.virtualbox.org/manual/UserManual.html#gui-vmgroups and https://docs.ansible.com/ansible/latest/inventory_guide/intro_inventory.html#how-variables-are-merged
From VirtualBox Docs:
The way the dynamic inventory parses the groups considers the
/
character as the delimiter for group assignment. As a consequence, we are unable to use nested groups in Ansible. If a user does not care about nested group, and assign multiple groups by simply using the/
character (e.g./TestGroup/TestGroup2
), the VirtualBox UI will show a deeply nested list of groups before displaying the actual VM. See vm-1 in the screenshot for an example.The example I provide shows 2 issues resulting from how groups are parsed:
vm-1 is not set up with nested groups, but is set up to participate in 3 top-level groups. vm-2 groups have a trailing comma (except for the last one).
I did not spot mentions about how groups are automatically inferred in the official docs: https://docs.ansible.com/ansible/latest/collections/community/general/virtualbox_inventory.html
Issue Type
Bug Report
Component Name
virtualbox inventory
Ansible Version
Community.general Version
Configuration
OS / Environment
My Host OS: 6.9.1-arch1-1 Vagrant: 2.4.1 VirtualBox: 7.0.18 r162988 VirtualBox VMs: bento/rockylinux-9 Vagrant images
Steps to Reproduce
I made a sample
Vagrantfile
to help illustrate. Notice that I'm purposefully trying to make the hierarchy of groups for vm-1 to be the reverse from lexicographical ordering.Ensure your VirtualBox host has a host-only network named vboxnet0 with
192.168.56.1/24
set up. TheVagrantfile
will also copy your SSH key into the VMs for convenience when using with Ansible.And my simple inventory file
And some sample group vars
Expected Results
I expected to see vm-1 have its variable resolved properly, in consideration for nested groups when using
/zgroup1/ygroup2/xgroup3
, and for vm-2 to be part of separate groups when using/othergroup1,/othergroup2,/othergroup3
For vm-1, if we were to consider this in a static inventory, it might look like this:
and
The same would be true with the dynamic inventory.
For vm-2, it should be part of the
othergroup1
,othergroup2
,othergroup3
groups.Actual Results
In this case, vm-1 appears to be correctly assigned, but watch out!
The
zgroup1
group vars wins because it's ordered last, lexicographically. This shows they're considered to be "on the same level".Also, vm-2 groups have a trailing
,
character which is incorrect. This is due to the code simply splitting on the/
character, so the,
remains.Code of Conduct