Ansible wait_for module

[Phil]

I want to see the polling when I use the wait_for module in my play. Using -vvvv doesn't show any output.

How do I see polling for the wait_for module as output on my screen while running the play?

[DeepThought · Accepted solution]

Hi Phil,

I am just thinking aloud. Why were you expecting the poll to be seen on the command line? I think things like the ssh command execution and its params and retries (do loop) are more likely to be seen. I think the wait_for module was designed differently and in my mind poll is not even being used in the wait for module as we are not monitoring a task on the other side. I think poll is more applicable when there is a task on the other end (managed hosts)

Sanjay

[Phil]

Hi Sanjay, you 'think' or you 'know' it was designed differently? 

Example below polls port 22 to become open. The default state is 'started'. I want to see the checks in the verbose output. There is a default of 1 second between checks.

I'm pretty dissapointed in this RHL community. I was under the impression instructors and RH developers helped out in this community.

Example below is polling port 22.

# Same as above but you normally have ansible_connection set in inventory, which overrides 'connection'
- name: Wait 300 seconds for port 22 to become open and contain "OpenSSH"
  wait_for:
    port: 22
    host: '{{ (ansible_ssh_host|default(ansible_host))|default(inventory_hostname) }}'
    search_regex: OpenSSH
    delay: 10

[oldbenko · Accepted solution]

I'm pretty dissapointed in this RHL community. I was under the impression instructors and RH developers helped out in this community.

---

So, @Phil, you are disappointed on the basis on one vague question you ever asked in RHLC, which wasn't even a question, but rather a demand for someone to solve your problem. I hope life rewards you with less hardship in the future.

First thing, if you want to achieve something, at least try to understand what people who take the time for your problems are telling you, and ask questions if you don't. That's what this forum is about. Tolerance and respect.

If you did that, you'd have realised one important difference between what you are doing and what @DeepThought rightly suggested, which is:

  - name: Wait for stuff.
    wait_for:
      port: 234
      delay: 3

This is a single task invocation. Compare this with how what you want to get out of it looks when you do it correctly:

  - name: Start async task.
    command: sleep 300
    async: 1500
    poll: 0
    register: status
  - name: Wait for async task.
    async_status:
      jid: "{{ status.ansible_job_id }}"
    register: job_status
    delay: 1
    retries: 3
    until: job_status.finished

Did you happen to notice not one, but two registered variables?

Did you happen to notice the indenting level in the delay attribute?

I think even the most superficial look at what you see above should tell you that what @DeepThought is thinking about is absolutely true and you should probably give more merit to what he's saying.

Is there anything unclear in the above?

If yes, please come aboard. We are here to help you understand things, not do your work for you.

Thanks.

[Phil]

@oldbenko Was asking @DeepThought deep thought to clarify because maybe he contributed to the module. I don't know if he contributed or wrote the module, that's why I was asking. Sometimes people say I think when they actually know.

I asked a question, no demands here. I didn't think it was a vague question.  Thank you for wishing me less hardship in the future but you really didn't have to get all butt hurt and spend the time ranting in the reply.

I'm still learning which is why I'm in this community. Thanks for the code output you posted. And no, even with the superficial look at the  code I'm not sure how it gives me the polling checks in live output with verbose mode.

Please don't  get all butt hurt again and  write another condescending reply.

[oldbenko]

No worries, @Phil. I am not taking this personally at all. It is in the interest of everyone (including you) that I pointed out that you were coming across as rather condescending, and I thought I'd better step in and clarify the affair.

And while I'm at it I might as well actually clarify stuff at hand.

From the indenting level of the delay attribute in wait_for task, it is clear this is a parameter for the task, and it is completely up to the internal implementation in the module as to how it handles it (that is what @DeepThought suggested).

In the second example though, you start a long running task (such as start a system service or reboot a machine). You make it an asynchronous task and give it some time to finish, making sure Ansible doesn't stall at it by setting poll to zero. You do remember you did though, it by registering a variable.

Then in the next task, you do a loop, which checks that the previous async task had finished (it was just an example - actually, what you're trying to do is also completely possible - instead of async_status, you just use the wait_for module, and forget the async stuff, but - read on).

Instead of using the wait_for module's delay parameter, you make it into an Ansible loop by setting the delay and retries attributes not at module level, but rather at task level - this is where Ansible loop control becomes aware of what you're trying to do is something repetitive, rather than just waiting for some random module to finish, and it starts reporting iterations.

Is the problem any clearer now? Feel free to ask for further clarifications, I'll be glad to expand.

Cheers.

[Phil]

@oldbenko Thanks so much for the help. A little bit clearer now. I'll mess around with it but will probably have a few more questions. Thanks again so much for the help. 

[bonnevil]

I think it's an intentional design decision not to verbosely output each poll attempt.  If you think about it, generally this task will be part of a play running against an inventory of many hosts, and all of those poll results would be interleaved -- it'd be really hard to read, and it'd add a bunch of load to the control node.

If you're really curious, the wait_for module is a Python script and you can look at the source to look under the hood.  ansible-doc wait_for shows the path on your system to look in: I'm seeing /usr/lib/python2.7/site-packages/ansible/modules/utilities/logic/wait_for.py on a Fedora box.  It's a core module, so the current upstream source can be browsed at https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/utilities/logic/wait_for.py as well.

There are probably some ways to work around this if tracking poll attempts really matters. 

[Phil]

@bonnevil Thanks ,for the help.

[DeepThought]

@bonnevil Thanks for the clarification