Thanks for all the replies.  I was not aware of the always_run feature 
(http://docs.ansible.com/playbooks_checkmode.html) so that answers my 
question.  Thank you.

Also, @laserllama nice meeting you at AnsibleFest this week

On Friday, May 23, 2014 8:29:23 AM UTC-4, Michael DeHaan wrote:
>
> always_run is there, yes, but ultimately, check mode (dry run) is kind of 
> a configuration management thing, and can get difficult in more step-wise 
> application deployment or orchestration tasks.
>
> I agree we're not going to make a behavior change to variable evaluation 
> in check mode.
>
> I'm unclear on why we need a variable to indicate whether we are in check 
> mode when always_run can be used for data gathering commands.
> It's not a workaround, it's a feature :)
>
>
>
>
> On Thu, May 22, 2014 at 1:20 PM, Tomasz Kontusz 
> <[email protected]<javascript:>
> > wrote:
>
>> On 22.05.2014 17:20, Marc Petrivelli wrote:
>>
>>> Variables that are brought into scope through the "register: var" when a
>>> task is executed are not available when a playbook is run with the 
>>> --check
>>> mode.
>>>
>> That depends on the task - if a given module supports check-mode (most of 
>> the ones bundled with Ansible do) it will give you *some* information.
>> Tasks using modules that do not support check mode are skipped by 
>> default, so you'd need a workaround
>>
>>  The work-around I have been using is to put defaults (for all those
>>> variables that will eventually be brought into scope using register) 
>>> using
>>> set_fact or group_vars/all or an included var file.
>>>
>> One way to work around it for modules that don't support check mode (like 
>> command/shell, which can't do it for obvious reasons :-)) is to have a 
>> data-gathering command with "always_run: yes", and then use that to decide 
>> if the target command should be run.
>>
>> For example:
>> - name: Get Jenkins's plugins
>>   shell: jenkins-cli -s {{ jenkins.url }} list-plugins | cut -f 1 -d ' '
>>   register: installed_plugins
>>   changed_when: False
>>   always_run: yes  # This gets run even in check mode, as it's safe to 
>> read a list of plugins
>>
>> - name: Install missing plugins
>>   shell: jenkins-cli -s {{ jenkins.url }} install-plugin -deploy {{ item 
>> }}
>>   with_items: jenkins.plugins
>>   when: item not in installed_plugins.stdout_lines
>>
>>
>>  I suggest changing the ansible --check mode to not evaluate those
>>> variables, in the when clause, normally brought into scope using 
>>> register.
>>>
>> That sounds like a pretty confusing behavior, and it would break a lot of 
>> existing plays.
>>
>>
>>  Does anyone else have this problem?  Did you use another work around? Do
>>> you like my idea of selectively evaluating variables that are 
>>> "registered"?
>>>
>>>  I did have this problem, and I still would sometimes like to have a 
>> variable telling me if I'm in check mode (I know I can create one with 
>> set_fact and always_run, but it's an ugly hack).
>> The only real workaround that won't make your --check runs useless is 
>> splitting tasks into probing the system part, and changing the system part 
>> (or writing modules that do this :-)).
>>
>>
>> -- 
>> 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] <javascript:>.
>> To post to this group, send email to [email protected]<javascript:>
>> .
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/ansible-project/537E31D4.4040207%40gmail.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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/a673e4dc-8490-4578-8791-5f1bb3d379eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to