I realize your are using includes. I was pointing out that you want to use roles for the benefit of the namespacing protection that roles have and includes do not. From what I see this is correct behavior for what you've implemented and not a bug. A role should give you the separate variable namespace scope you seem to be expecting. <tim/>
On Mon, Jul 27, 2015 at 2:17 PM, Kathy Allen <[email protected]> wrote: > Thank you. However, our playbooks don't use roles. For our deployment > orchestration, it doesn't seem necessary, or at least it works well without > them. > > Can anyone speak to how that variable is getting set as the playbook > executes the second include? Will this absolutely not work without roles? > > On Friday, July 24, 2015 at 7:16:29 AM UTC-7, Timothy Appnel wrote: >> >> If I am following what behavior you are looking for (what you describe is >> how includes are intended to work) your playbook includes should be >> implemented as a role and then called with parameters. See if the added >> namespacing protections roles have, but includes does not kicks in. >> >> <tim/> >> > -- 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/CAOMCme7fOihJx948YkHWizGs5CRwdFPvLXg8imP1h2VRKrbCJQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
