hack/build-rpms.sh: fix yum-builddep failures #5663
Conversation
Codecov Report
@@ Coverage Diff @@
## main #5663 +/- ##
==========================================
- Coverage 43.03% 43.02% -0.01%
==========================================
Files 123 123
Lines 12286 12286
==========================================
- Hits 5287 5286 -1
- Misses 6491 6492 +1
Partials 508 508 |
This comment was marked as outdated.
This comment was marked as outdated.
1df22fb to
93b6856
Compare
93b6856 to
e8eaad6
Compare
|
OK, it kind of works now... producing a different error: |
This tries to solve a failure in building rpms, and consists of two fixes. 1. Looking into cri-o CI, this error seems common: http://vault.centos.org/centos/7/os/Source/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2600:1f16:c1:5e03:a992:8ee1:99d2:6f8: Network is unreachable" http://vault.centos.org/centos/7/os/Source/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2600:1f16:c1:5e03:a992:8ee1:99d2:6f8: Network is unreachable" http://vault.centos.org/centos/7/os/Source/repodata/repomd.xml: [Errno 14] HTTPS Error 301 - Moved Permanently [ERROR] hack/build-rpms.sh:31: `yum-builddep -y "${OS_RPM_SPECFILE}"` exited with status 1. Apparently, vault.centos.org resolves to both IPv4 and IPv6 addresses, and one of the addresses is used (randomly, I presume). If the node does not have IPv6 connectivity (as it seems to be the case), as a result we have 50% chance of failure. Work around this by asking yum to only use IPv4 for address resolving. 2. vault.centos.org is super slow, resulting in numerous timeouts, often fatal: http://vault.centos.org/centos/7/os/Source/repodata/repomd.xml: [Errno 12] Timeout on http://vault.centos.org/centos/7/os/Source/repodata/repomd.xml: (28, 'Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds') http://vault.centos.org/centos/7/os/Source/repodata/repomd.xml: [Errno 12] Timeout on http://vault.centos.org/centos/7/os/Source/repodata/repomd.xml: (28, 'Connection timed out after 30001 milliseconds') http://vault.centos.org/centos/7/os/Source/repodata/repomd.xml: [Errno 12] Timeout on http://vault.centos.org/centos/7/os/Source/repodata/repomd.xml: (28, 'Connection timed out after 30001 milliseconds') http://vault.centos.org/centos/7/os/Source/repodata/repomd.xml: [Errno 12] Timeout on http://vault.centos.org/centos/7/os/Source/repodata/repomd.xml: (28, 'Connection timed out after 30001 milliseconds') [ERROR] hack/build-rpms.sh:38: `yum-builddep -y "${OS_RPM_SPECFILE}"` exited with status 1. Let's use mirrors.kernel.org instead. Signed-off-by: Kir Kolyshkin <[email protected]>
e8eaad6 to
6c3144a
Compare
|
OK, this is centos 7 source repo, which is configured without mirrors, so yum has no alternative but to use vault.centos.org. And vault.centos.org is super slow for some reason. I tried it locally and also see timeouts. Let's try to use kernel.org mirror which has the sources, too. |
|
@kolyshkin: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
All right, that finally works! @haircommander PTAL |
|
amazing! thanks for digging into this @kolyshkin /approve @cri-o/cri-o-maintainers PTAL |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: haircommander, kolyshkin The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Pretty slick @kolyshkin |
|
/lgtm |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/cherry-pick release-1.23 |
|
@kolyshkin: new pull request created: #5668 DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/cherry-pick release-1.22 |
|
/cherry-pick release-1.21 |
|
@haircommander: new pull request could not be created: failed to create pull request against cri-o/cri-o#release-1.22 from head openshift-cherrypick-robot:cherry-pick-5663-to-release-1.22: status code 422 not one of [201], body: {"message":"Validation Failed","errors":[{"resource":"PullRequest","code":"custom","message":"No commits between cri-o:release-1.22 and openshift-cherrypick-robot:cherry-pick-5663-to-release-1.22"}],"documentation_url":"https://docs.github.com/rest/reference/pulls#create-a-pull-request"} DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
@haircommander: new pull request created: #5699 DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/kind ci
/kind failing-test
/kind flake
What this PR does / why we need it:
This tries to solve a failure in building rpms, and consists of two fixes.
Apparently, vault.centos.org resolves to both IPv4 and IPv6 addresses,
and one of the addresses is used (randomly, I presume). If the node
does not have IPv6 connectivity (as it seems to be the case), as a
result we have 50% chance of failure.
Work around this by asking yum to only use IPv4 for address resolving.
Let's use mirrors.kernel.org instead.
Which issue(s) this PR fixes:
None
Special notes for your reviewer:
Does this PR introduce a user-facing change?