How to retry up to N times (on failures) with win_get_url

[SurferL]

Sometimes when using win_get_url, it fails with my downloads with fatal: []: UNREACHABLE! => {"changed": false, "msg": "ssl: (u'http', u'Bad HTTP response returned from server. Code 500')", "unreachable": true}

As you can imagine, after an hour or so of building this is a bit annoying...

How would you encapsulate the win_get_url command to retry N times on failures like these?

--------

I've tried something along the lines of:

- name: win | Download packages

  win_get_url:

    url: "{{ item.url }}"

    dest: "{{ tmp_working_dir }}/{{ item.name }}"

    timeout: 600

  with_items: "{{ install_packages }}"

  retries: 3

  delay: 5

  register: package_result

  until: package_result|succeeded

  ignore_errors: yes

- name: win | Report errors with downloading files

  fail:

    msg: "Unable to download {{ package_result.url }}: {{ package_result.response|default(package_result.msg) }}"

  when: not package_result|succeeded 

But even if it fails, it doesn't retry and exits.

Can anyone point to where I've made an error?

Thanks! 

[J Hawkesworth]

Could you show the error in context somehow?  I think your playbook looks fine, but my guess is the failure isn't between the windows box and the webserver you are downloading from, but instead ansible isn't able to talk to the windows box.

I.e. you are handling a failure here
                        v
ansible -> windows box -> webserver

but the failure is here, perhaps:
         v 
ansible -> windows box -> webserver

One thing you can try if its is failing between ansible and the windows box is making sure you have latest pywinrm installed.

You can try increasing some of the winrm timeouts too.

I have had comms fails like this that turned out to be because I was pointing at a single core vm which had just had windows updates applied and it was running ngen which recompiles much .net code and wipes out the cpu while it is running, seemingly leaving no cpu time for anything else.  Not a lot ansible can do under the circumstances other than wait and retry when the cpu isn't wiped out.

There may other things you can try (possibly using message encryption which is available if you are using pywinrm) if the problem is actually comms, but worth double checking where the problem is occurring first.

Hope this helps,

Jon

[SurferL]

Hi Jon, 

Thanks for the response! 

I think you're right with where the error is occurring! I'll try increasing winrm timeouts. Would the best place to do this be in group_vars? Or would it be possible to add winrm_timeout when calling ansible_playbook on the command line?