8000 fix: switching to the registry addon for olm testing (#40334) by shawkins · Pull Request #40349 · keycloak/keycloak · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

fix: switching to the registry addon for olm testing (#40334) #40349

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 10, 2025

Conversation

shawkins
Copy link
Contributor
@shawkins shawkins commented Jun 9, 2025

closes: #40099

Signed-off-by: Steve Hawkins shawkins@redhat.com
(cherry picked from commit eb96b4a)

@vmuzikar
Copy link
Contributor
vmuzikar commented Jun 9, 2025

Seems there is a related error:

Get "http://192.168.49.2:5000/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

@shawkins
Copy link
Contributor Author
shawkins commented Jun 9, 2025

Seems there is a related error:

My only conclusion is that every single part of Docker is awful...

I've rerun the job to help clarify if this is error is deterministic.

The only reference for something like this is in https://minikube.sigs.k8s.io/docs/handbook/vpn_and_proxy/ which mentions a proxy blocking access.

I can also:

  • simply add no_proxy, but I don't believe that should be coming into play here
  • do an earlier print out of the minikube ip. However you can see from the other runs on 26.2 that the dockerHost is reported as 192.168.49.2
  • something else, such as getting the registry pod status / log to try to determine why it's failing
  • try doing our own deployment / external start of the registry - but I wouldn't want to bet on whether that will work either

closes: keycloak#40099

Signed-off-by: Steve Hawkins <shawkins@redhat.com>
(cherry picked from commit eb96b4a)
@shawkins shawkins force-pushed the backport-40334-26.2 branch from 51df5bd to 602a7d5 Compare June 9, 2025 16:03
@vmuzikar
Copy link
Contributor
vmuzikar commented Jun 9, 2025

What if we used podman as the minikube driver instead? :D

@shawkins
Copy link
Contributor Author
shawkins commented Jun 9, 2025

What if we used podman as the minikube driver instead? :D

It's still considered experimental of course - and we'd still need to run a registry...

Since the second run passed we can rule out a proxy issue. I also see no reason why the ip would change given what I've seen locally and with every other test run, but just in case I've changed it to use a subnet and minikube ip - along with a print out of the ip - that thrid time ran as well, and confirmed the usage of 192.168.49.2.

I've set it run repeatedly to see how often we might encounter this problem.

@shawkins shawkins force-pushed the backport-40334-26.2 branch 2 times, most recently from d2d0238 to 602a7d5 Compare June 9, 2025 19:12
@shawkins
Copy link
Contributor Author
shawkins commented Jun 9, 2025

@vmuzikar the olm tests run 53 more times without a problem, so I'm thinking we are safe to merge even if we've only reduced, but not fully eliminated the flakiness.

@vmuzikar
Copy link
Contributor

@shawkins Agree, let's merge it.

Could you please prepare a PR to align the changes in main too?

@vmuzikar vmuzikar merged commit 9e6e9e3 into keycloak:release/26.2 Jun 10, 2025
101 checks passed
@shawkins
Copy link
Contributor Author

Could you please prepare a PR to align the changes in main too?

I can, but there was no indication from the additional runs that a different ip is being used - they were done still with a fixed ip as the registry. It also won't prevent an issue if we switch to a different driver. We'd have to instead look at all the possible default ip assignments ranges and proactively add those to the insecure-registry settings.

@vmuzikar
Copy link
Contributor

@shawkins Yeah, seems like the IP is actually stable. But I'd still prefer to have the branches aligned with the same workflow for the minikube.

shawkins added a commit to shawkins/keycloak that referenced this pull request Jun 27, 2025
…keycloak#40349)

closes: keycloak#40099

(cherry picked from commit eb96b4a)

Signed-off-by: Steve Hawkins <shawkins@redhat.com>
(cherry picked from commit 9e6e9e3)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0