Multiple conditions not working

71 views
Skip to first unread message

Pranay Nanda

unread,
May 27, 2018, 11:51:15 AM5/27/18
to Ansible Project
I want to run few tasks in shell if they satisfy a condition. Strangely the task runs if the second condition is satisfied even though the first one fails.

  name: ods
  shell: "/something {{state}}"
  when: ((ods) and (not (ansible_hostname | search("demlh*"))))
  register: sss_ods_out
  notify: output ods
  ignore_errors: yes

Here sss_ods is a variable defined in a vars file. If I remove the latter condition the task would run but I want both the conditions to be satisfied for the task to run and I can't understand where am I going wrong.

Dan Linder

unread,
May 27, 2018, 1:00:17 PM5/27/18
to Ansible Project
The "when" stanza performs a AND when there are multiple when conditions (http://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html#the-when-statement).

Whenever I encounter a problem with 'when' I try to break it up to multiple lines so the numerous parenthesis aren't causing confusion:

 - name: ods
   shell: "/something {{state}}"
   when:

    - ods

    - not (ansible_hostname | search("demlh*"))

   register: sss_ods_out
   notify: output ods
   ignore_errors: yes

With that you might be able to deduce why the "AND" clause isn't working as expected.

It might also be that the "ansible_hostname | search(...)" might need to change to "ansible_hostname is search(...)" (change | to is).

If not, can you provide what "ods" contains?  A simple "debug:" before that call should suffice.

Dan Linder

unread,
May 27, 2018, 1:04:11 PM5/27/18
to Ansible Project
I just noticed, if you break the when into two clauses, instead of doing "not (...)" you can do this:

 - name: ods
   shell: "/something {{state}}"
   when:

    - ods

    - ansible_hostname is not search("demlh*")

   register: sss_ods_out
   notify: output ods
   ignore_errors: yes

Pranay Nanda

unread,
May 27, 2018, 1:24:01 PM5/27/18
to Ansible Project
You're a hero! Splitting does the job. I still wonder why previous logic did not work.

Dan Linder

unread,
May 27, 2018, 2:12:37 PM5/27/18
to ansible...@googlegroups.com
I've run into subtle and hard-to-spot logic bugs (Ansible and elsewhere) that were 'correct' but magically solved when rewritten.  I agree that your syntax looks spot on, but breaking it out into multiple statements might make it easier to troubleshoot later on too.

Glad it worked!

--
You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/s3I_l8M-7SU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-project+unsubscribe@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/801d7920-39c0-40a1-a173-2c4cabf7db34%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
***************** ************* *********** ******* ***** *** **
"If you wish to make an apple pie from scratch, 
  you must first invent the universe."
  -- Carl Sagan

"Quis custodiet ipsos custodes?"
    (Who can watch the watchmen?)
    -- from the Satires of Juvenal

"I do not fear computers, I fear the lack of them."
    -- Isaac Asimov (Author)
** *** ***** ******* *********** ************* *****************
Reply all
Reply to author
Forward
0 new messages