# variable set to a default value in play vars unexpectedly becomes not the default value **URL:** \ **Category:** Ansible Project\ **Created:** [July 22, 2015, 12:04am UTC](https://forum.ansible.com/t/variable-set-to-a-default-value-in-play-vars-unexpectedly-becomes-not-the-default-value/18817 "2015-07-22T00:04:07Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Kathy\_Allen](https://avatars.discourse-cdn.com/v4/letter/k/839c29/32.png) [@Kathy\_Allen](https://forum.ansible.com/u/Kathy_Allen)\ **Post date:** [July 22, 2015, 12:04am UTC](https://forum.ansible.com/t/variable-set-to-a-default-value-in-play-vars-unexpectedly-becomes-not-the-default-value/18817/1 "2015-07-22T00:04:07Z")
Hi there, I’m using ansible 1.9.2. We don’t use ansible for configuration management, but instead for deployment automation. I’m trying to set some conditions early on in a play so that the right tasks get executed under the right conditions later in the play. This play is called multiple times from a playbook. I thought I had a good thing going here, until I realized upon the 2nd include of the play, the default I intended for a var was set to a value which got set within the first include of the play. I had thought that upon the 2nd include of the play, all vars would get set again to my intended default value. But that didn’t happen. The details of what’s happening, including the playbook and play are at the bottom… And when you get there … Is this expected? Is this a bug? Shouldn’t it work the way I expect? The reason why I’m even going down this road is because ansible doesn’t support conditionally including a play within a playbook. “Conditions on include don’t apply to the include itself, it is applied to the tasks included”, from a previous post. Thank you in advance! kallen ` ansible\_1.9.2 $ cat sushi\_playbook.yml ---
**Author:** ![Kathy\_Allen](https://avatars.discourse-cdn.com/v4/letter/k/839c29/32.png) [@Kathy\_Allen](https://forum.ansible.com/u/Kathy_Allen)\ **Post date:** [July 23, 2015, 7:21pm UTC](https://forum.ansible.com/t/variable-set-to-a-default-value-in-play-vars-unexpectedly-becomes-not-the-default-value/18817/2 "2015-07-23T19:21:41Z")
bump? ---
**Author:** ![Timothy\_Appnel1](https://avatars.discourse-cdn.com/v4/letter/t/278dde/32.png) [@Timothy\_Appnel1](https://forum.ansible.com/u/Timothy_Appnel1)\ **Post date:** [July 24, 2015, 2:15pm UTC](https://forum.ansible.com/t/variable-set-to-a-default-value-in-play-vars-unexpectedly-becomes-not-the-default-value/18817/3 "2015-07-24T14:15:45Z")
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. ---
**Author:** ![Kathy\_Allen](https://avatars.discourse-cdn.com/v4/letter/k/839c29/32.png) [@Kathy\_Allen](https://forum.ansible.com/u/Kathy_Allen)\ **Post date:** [July 27, 2015, 6:17pm UTC](https://forum.ansible.com/t/variable-set-to-a-default-value-in-play-vars-unexpectedly-becomes-not-the-default-value/18817/4 "2015-07-27T18:17:24Z")
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? ---
**Author:** ![Timothy\_Appnel1](https://avatars.discourse-cdn.com/v4/letter/t/278dde/32.png) [@Timothy\_Appnel1](https://forum.ansible.com/u/Timothy_Appnel1)\ **Post date:** [July 27, 2015, 7:37pm UTC](https://forum.ansible.com/t/variable-set-to-a-default-value-in-play-vars-unexpectedly-becomes-not-the-default-value/18817/5 "2015-07-27T19:37:10Z")
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. ---
**Author:** ![Brian\_Coca](https://avatars.discourse-cdn.com/v4/letter/b/6de8d8/32.png) [@Brian\_Coca](https://forum.ansible.com/u/Brian_Coca)\ **Post date:** [July 27, 2015, 8:22pm UTC](https://forum.ansible.com/t/variable-set-to-a-default-value-in-play-vars-unexpectedly-becomes-not-the-default-value/18817/6 "2015-07-27T20:22:56Z")
So your expectation is incorrect, as any play level variable modified during the play is still modified during any subsequent part of the play, includes are not namespaced, in a play you only have 2 scopes: play vars and host vars, both carry forward any changes made at any point in the play. In the case of hostvars they'll carry over to subsequent plays also. What you want is 2 plays that set the same default vars and you can do include #1 in the first play and include #2 in the 2nd, then the vars will look like what you expect. ---
**Author:** ![Kathy\_Allen](https://avatars.discourse-cdn.com/v4/letter/k/839c29/32.png) [@Kathy\_Allen](https://forum.ansible.com/u/Kathy_Allen)\ **Post date:** [July 27, 2015, 11:58pm UTC](https://forum.ansible.com/t/variable-set-to-a-default-value-in-play-vars-unexpectedly-becomes-not-the-default-value/18817/7 "2015-07-27T23:58:43Z")
Thank you Brian. That’s the Clue I needed. I’ll rethink this… kallen