Hello,
I'm trying to work on a requirement to have the host pattern change
depending on certain host groups or parameters being passed to the playbook
:
This is what I need exactly :
1. When an external var cli_hosts is provided, this playbook runs on the
provided host pattern
2. If not, it defaults to a group 'new_instances', I've used this group to
indicate new instances that are spawned in a parent playbook, which
includes this play via include statement.
I could have used cli_hosts ( by using set_fact ) in the parent playbook,
expecting that this one will pick it up, but that doesn't work. Passing it
as a parameter in the include statement doesn't work either.
>From what I understand, this is because host patterns are not in the
set_fact scope. Also, set_fact is host specific fact, so it gets set in the
pattern of the original play (localhost in my case). I think it would help
if there is a way to access the global scope somehow. I'm not sure why
passing it as a parameter not work ( via include )
3. If either of the above two are not present, default to the entire
cluster.
This is the play I tried :
---
- name: Test Playbook
hosts: localhost
connection: local
tasks:
- name: create a custom group
add_host: name=test groups=new_instances
- debug: msg="{{cli_hosts|default('new_instances' in groups and
'new_instances' or null)|default('test_cluster')}}"
- name: Deploy to hosts
hosts: "{{cli_hosts|default('new_instances' in groups and 'new_instances'
or null)|default('test_cluster')}}"
tasks:
debug:
If you run this, in the first play debug prints the correct, expected
output, but fails in the next play when used for the host pattern. I guess
this is because of 'new_instances' in groups in default, which works
correctly in the first play.
So, question : why does the host pattern fail for the same expression?
Reusing playbooks in other plays gets cumbersome due to the limitations in
what can be passed in include. For host patterns, a way to enumerate the
hosts would help, as I can reconstruct the group in the included play.
Also, using roles to abstract things doesn't fit well in all scenarios. If
this fails, the only solution I see is to duplicate the logic in the parent
play.
Thanks,
Raghu
--
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 post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/4547d7fc-68dc-44b8-a82e-6aadb2b8d90c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
