On 9/16/22 10:23 AM, Brian Coca wrote:
vars_files:
- group_vars/web/main.yml
Do not load group_vars/host_vars directly, this is the job of the vars plugin,
you create duplicate entries and mask the actual expected values from
normal precedence resolution.
The vars_files thing was my suggestion, and I heartily endorse Brian's
stance on this — i.e. to not to. "This works in my little test" and
"this feels shaky" were too subtle. Just don't.
Reflecting further on the nature of the problem as you re-stated it:
Thanks, but that seems to be making the play conditional on whether
there are any 'web' hosts in the play.
What I am looking for is a way to access those group_vars regardless
of whether there are any such hosts in the play.
If you have a need to access these group variables' values even when
there are no host members in the relevant group(s) in your inventory,
then I assert that these values are improperly scoped. By that I mean
their "true root" should not be that group, but rather some other source
that's available to all the places that need it. For example
*---
# group_vars/all/web_centric_vars.yml
web_foopass: sEcrEtSauCE
...*
*---**
**# group_vars/web/main.yml**
**foopass: "{{ web_foopass }}"**
**...*
With those two files in place, your initial play becomes
*---
- name: do API related work*
* hosts: localhost*
* connection: local*
* become: false*
* gather_facts: false*
* tags: api*
* tasks:*
* - name: populate secret for use elsewhere
*
* community.aws.aws_secret:*
* name: foopass*
* secret: "{{ web_foopass }}"
...**
*
The later web-scoped play can use 'foopass' from the
'group_vars/web/main.yml' file. This should always work regardless of
how many hosts – including zero – are in the 'web' group.
One could reasonably argue that, given 'web_foopass' in an 'all/*' file,
there's no need for 'foopass' in a 'group_vars/web' file. However, a
'host_vars/web' file or some other higher precedence source my override
the group_vars 'foopass' in certain circumstances. We don't know how
much complexity you've left out, so do it the way that will make the
most sense to the maintainers.
--
Todd
--
You received this message because you are subscribed to the Google Groups "Ansible
Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/08d41c56-2379-f336-d69a-7bc48765f0e7%40gmail.com.
