Re: group restrictions?

Hello guenter, On sie 23, dev wrote: Yes, you can have as many inventory groups as you want. However, during execution Ansible "collapses" inventory variables on three distinct levels: - the variables in 'ansible/inventory/group_vars/all/' are merged into - the variables in 'ansible/inventory/group_vars/*/' and then merged with - the variables in 'ansible/inventory/host_vars/<host>/*/' During the merge process, the variables of the same name from lower levels override the variables from higher levels. For example, if you define 'resources__paths' in the 'ansible/group_vars/all/resources.yml' file, and then define the same 'resources__paths' variable in 'ansible/host_vars/<host>/resources.yml' file, the value of the variable defined on the host level will take precedence. This of course has a problem on the "group level", since all groups are esentially on the same level and the values will be read from the inventory groups in the order they are defined (alphabetical according to the filenames, I think). To aid with that, you can define in each group the 'ansible_group_priority' variable with a numerical value which can change the final group ordering. But you still have one 'resources__group_paths' variable to work with so that's another problem to solve. One way to go about it is to define additional variables, one per group, and then merge them either in the 'all' level for multiple hosts, or on the 'host' level for a single host. For example, let's say you have an inventory like this: #v+ [group_alpha] hostname [group_beta] hostname [group_gamma] hostname #v- You can then define variables for that group in 'ansible/inventory/group_vars/<group>/resources.yml' file, for each group: #v+ --- # ansible/inventory/group_vars/group_alpha/resources.yml resources__group_alpha_paths: [ '/tmp/alpha' ] #v- #v+ --- # ansible/inventory/group_vars/group_beta/resources.yml resources__group_beta_paths: [ '/tmp/beta' ] #v- #v+ --- # ansible/inventory/group_vars/group_gamma/resources.yml resources__group_gamma_paths: [ '/tmp/gamma' ] #v- And to tie it all together, let's add all of the lists to each other on the highest level so that if a host is in one of the groups, they will see the proper values: #v+ --- # ansible/inventory/group_vars/all/resources.yml resources__group_paths: '{{ q("flattened", resources__group_alpha_paths | d([]) + resources__group_beta_paths | d([]) + resources__group_gamma_paths | d([])) }}' #v- Notice the 'd([])' statements - this is needed so that if a host is not in one of the groups, it doesn't result in an undefined variable and role being broken. Yes, this system is cumbersome, brittle and needs to be hand-holded on each change when you add or remove groups. But that's the nature of Ansible and inventories based on YAML files. A better alternative would be to set up some kind of dynamic inventory which returns the variables you want for each host when Ansible calls it. But that might be overkill depending on the size of your environment. Just to reiterate - this is done by Ansible itself during inventory processing, there's no way to handle this in the roles themselves. Well, actually there is - you just write roles with all the group variables that you want. But DebOps roles are different - they are meant to be read-only, so that updates can be possible. That's why we need to work around this limitation with an additional variable that merges the group variables, described above. Please don't use 'hash_behaviour=merge', even its original proponent discourages it[1]. It was also deprecated in Ansible and will be removed in the future[2]. Better not to rely on it which leads to broken behaviour. [1]: https://www.reddit.com/r/ansible/comments/a7x92q/in_which_case_hash_behav... [2]: https://github.com/ansible/ansible/pull/63300 Yes. That's true, but there are ways to work around that. Some of the newer DebOps roles that rely on a custom filter to process their variables, use a special '<role>__combined_variables' pattern which are variables that define a list of default variables to work on. These specific variables can be redefined by the user in the inventory to let the role process multiple group variables or even data from other sources like 'consul' or 'etcd' databases, when processed via lookup plugins. But the roles you are interested in ('apt_install', 'resources') currently don't use this system. You can check the extended example above to see how the issue of multiple inventory groups can be solved in the inventory itself. If this is something that you plan to rely on often, I would also consider rewriting this into a proper role or multiple roles. The 'resources' role + configuration via Ansible inventory is a good "staging setup", but encapsulating all this into a proper Ansible role might give you access to more tools like proper 'systemd' or 'service' Ansible modules, idempotency, etc. You can then apply that role via its playbook with other DebOps playbook and services that you use, for example: debops common service/mariadb_server custom_proxmox_role -l host1,host2 Let us know if you have any other questions, and have fun with DebOps. :-) -- Maciej