Details
-
Type:
Improvement
-
Status: Open (View Workflow)
-
Priority:
Minor
-
Resolution: Unresolved
-
Component/s: azure, pkg.jenkins.io
-
Labels:None
-
Similar Issues:
Description
(Please note that selected "component" might be completely wrong.)
I am using an automated upgrade based on Ansible, where it first downloads the specific Jenkins core debian package; and I am upgrading to an estimated > 95% of the weekly release versions of Jenkins 2 within 1-5 days after their release.
This was running without problem from about December 2016 (Jenkins v2.35) until today: Jenkins v2.134, that is for almost exactly 100 versions (interesting coincidence)...
Today it failed (at least 5 times in a row within ~30 minutes) like this:
PLAY [all] ********************************************************************GATHERING FACTS ***************************************************************ok: [jenkins2.ACME.com]TASK: [jenkins | install | Download specific jenkins version] ***************** failed: [jenkins2.ACME.com] => {"dest": "/tmp/jenkins-2.134.deb", "failed": true, "response": "Request failed: <urlopen error timed out>", "state": "absent", "status_code": -1, "url": "http://pkg.jenkins.io/debian/binary//jenkins_2.134_all.deb"} msg: Request failedFATAL: all hosts have already failed -- abortingPLAY RECAP ******************************************************************** to retry, use: --limit @/home/USER/jenkins-install.retryjenkins2.ACME.com : ok=1 changed=0 unreachable=0 failed=1
My "solution" (or rather workaround?) was to set a timeout for Ansible "get_url" task (instead of default timeout of 10s), i.e. the line with "timeout: 20" is new:
# tasks file for installing jenkins - name: install | Download specific jenkins version get_url: url: "{{ jenkins_pkg_url }}/jenkins_{{ jenkins_version }}_all.deb" timeout: 20 dest: "/tmp/jenkins-{{ jenkins_version }}.deb" when: jenkins_version is defined and jenkins_version != ''
Please note that a manual download from https://pkg.jenkins.io/debian/ was also rather slowly starting and showing this target URL:
... but is NOW (~30 min later) starting fast again => so maybe the cloud is the "cause of and solution to all problems" (adapted quote of Homer Simpson)?
Thanks for reporting this and indeed sometimes we notice that azure blob storage can be slower but we don't have yet a solution to that