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)?