Test failure `':distribution:docker:buildIronBankDockerImage'`

[n1v0lg]

CI Link

https://gradle-enterprise.elastic.co/s/qddwlyzx6ssx4

Repro line

N/A

Does it reproduce?

Didn't try

Applicable branches

main

Failure history

No response

Failure excerpt

Failing with:

Execution failed for task ':distribution:docker:buildIronBankDockerImage'.
> A failure occurred while executing org.elasticsearch.gradle.internal.docker.DockerBuildTask$DockerBuildAction
  > Process 'command 'docker'' finished with non-zero exit value 1

Digging into console log:

|  > [stage-1  2/11] RUN yum update --setopt=tsflags=nodocs -y &&     yum install --setopt=tsflags=nodocs -y       nc shadow-utils zip findutils unzip procps-ng &&     yum clean all:  
| 0.900 Updating Subscription Management repositories.  
| 0.900 Unable to read consumer identity    
| 0.907     
| 0.907 This system is not registered with an entitlement server. You can use subscription-manager to register. 
| 0.907     
| 3.337 Red Hat Universal Base Image 9 (RPMs) - BaseOS  144 kB/s | 336 kB     00:02     
| 3.339 Errors during downloading metadata for repository 'ubi-9-baseos-rpms':  
| 3.339   - Curl error (52): Server returned nothing (no headers, no data) for https://cdn-ubi.redhat.com/content/public/ubi/dist/ubi9/9/x86_64/baseos/os/repodata/76bf3bee790392f49720ed87c860e07c2c39fb63e386c1cedd717821ad13915f-primary.xml.gz [Empty reply from server]    
| 3.369 Error: Failed to download metadata for repo 'ubi-9-baseos-rpms': Yum repo downloading error: Downloading error(s): repodata/76bf3bee790392f49720ed87c860e07c2c39fb63e386c1cedd717821ad13915f-primary.xml.gz - Cannot download, all mirrors were already tried without success   

I can't tell if this is just a network glitch or a real issue, so opening as a precaution.

[elasticsearchmachine]

Pinging @elastic/es-delivery (Team:Delivery)

[mark-vieira]

I see only two instances of this task failing in the past month, and both this same transient error. The root cause looks like the remote yum repo returning an empty response. I'm pretty confident this is just a blip and not something broken with our Dockerfile. Closing for now.