Skip to content
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

Define a new remote.DefaultTransport. #1165

Merged
merged 4 commits into from
Nov 11, 2021

Conversation

mattmoor
Copy link
Collaborator

@mattmoor mattmoor commented Nov 4, 2021

The first commit here reverts #1163 which went in before I could change it to the transport-based option.

Previously we used http.DefaultTransport (on which this is based),
but this uses a default dial timeout of 30s, which when we (by default)
wrap things in 5x retries can lead to ~150s delays simply pinging
an http-based registry.

If folks encounter issues with this via the library they can restore
the current behavior with:

remote.WithTransport(http.DefaultTransport)

If folks encounter issues with this via crane they can restore the
current behavior with:

--dial-timeout 30s

@google-cla
Copy link

google-cla bot commented Nov 4, 2021

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

@mattmoor
Copy link
Collaborator Author

mattmoor commented Nov 4, 2021

@googlebot I fixed it.

@google-cla
Copy link

google-cla bot commented Nov 4, 2021

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

@mattmoor
Copy link
Collaborator Author

mattmoor commented Nov 4, 2021

@googlebot I fixed it.

@google-cla
Copy link

google-cla bot commented Nov 4, 2021

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

@mattmoor
Copy link
Collaborator Author

mattmoor commented Nov 4, 2021

@googlebot I fixed it.

@google-cla
Copy link

google-cla bot commented Nov 4, 2021

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

@mattmoor
Copy link
Collaborator Author

mattmoor commented Nov 4, 2021

image

omg I hate you CLA bot

@mattmoor
Copy link
Collaborator Author

mattmoor commented Nov 4, 2021

Switched to the old email 🙃

@mattmoor
Copy link
Collaborator Author

mattmoor commented Nov 5, 2021

Fixed the gcrane test that assumed http.DefaultTransport was the default transport to use WithTransport.

@codecov-commenter
Copy link

codecov-commenter commented Nov 5, 2021

Codecov Report

Merging #1165 (3997975) into main (6cb23fb) will decrease coverage by 0.00%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #1165      +/-   ##
==========================================
- Coverage   75.24%   75.23%   -0.01%     
==========================================
  Files         108      108              
  Lines        7857     7855       -2     
==========================================
- Hits         5912     5910       -2     
  Misses       1379     1379              
  Partials      566      566              
Impacted Files Coverage Δ
pkg/v1/remote/options.go 69.23% <100.00%> (ø)
pkg/v1/remote/transport/ping.go 91.46% <100.00%> (-0.21%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6cb23fb...3997975. Read the comment docs.

Copy link
Collaborator

@imjasonh imjasonh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks okay to me. I'm not super in love with making crane users think about the dial timeout flag, but I guess it's okay to let them get back to previous behavior if they want it.

pkg/gcrane/copy_test.go Show resolved Hide resolved
@imjasonh
Copy link
Collaborator

Friendly ping. If we do a release soon do we feel like we need to get this included in it?

@mattmoor
Copy link
Collaborator Author

Rebasing now, then I'll add a commit for the xcr.io thing.

Previously we used `http.DefaultTransport` (on which this is based),
but this uses a default dial timeout of 30s, which when we (by default)
wrap things in 5x retries can lead to ~150s delays simply pinging
an http-based registry.

If folks encounter issues with this via the library they can restore
the current behavior with:
```go
remote.WithTransport(http.DefaultTransport)
```

If folks encounter issues with this via `crane` they can restore the
current behavior with:
```
--dial-timeout 30s
```
cmd/crane/cmd/root.go Outdated Show resolved Hide resolved
jonjohnsonjr added a commit to jonjohnsonjr/go-containerregistry that referenced this pull request Dec 27, 2022
This implements a "happy eyeballs" (RFC 6555) style of race in order to
speed up http fallback during registry pings.

This heavily borrows code from net/dial.go which implements this same
kind of race for dual stack DNS.

Rather than waiting for the initial "https" ping to time out completely
before attempting to use "http", we will instead start a second fallback
ping after 300ms and return whichever response comes back first.

This partially reverts the portion of google#1165 that reduced the dial
timeout to workaround this issue.
jonjohnsonjr added a commit to jonjohnsonjr/go-containerregistry that referenced this pull request Dec 27, 2022
This implements a "happy eyeballs" (RFC 6555) style of race in order to
speed up http fallback during registry pings.

This heavily borrows code from net/dial.go which implements this same
kind of race for dual stack DNS.

Rather than waiting for the initial "https" ping to time out completely
before attempting to use "http", we will instead start a second fallback
ping after 300ms and return whichever response comes back first.

This partially reverts the portion of google#1165 that reduced the dial
timeout to workaround this issue.
jonjohnsonjr added a commit to jonjohnsonjr/go-containerregistry that referenced this pull request Dec 27, 2022
This implements a "happy eyeballs" (RFC 6555) style of race in order to
speed up http fallback during registry pings.

This heavily borrows code from net/dial.go which implements this same
kind of race for dual stack DNS.

Rather than waiting for the initial "https" ping to time out completely
before attempting to use "http", we will instead start a second fallback
ping after 300ms and return whichever response comes back first.

This partially reverts the portion of google#1165 that reduced the dial
timeout to workaround this issue.

Also, drop unused parseChallenge to appease the linter.
imjasonh pushed a commit that referenced this pull request Dec 28, 2022
This implements a "happy eyeballs" (RFC 6555) style of race in order to
speed up http fallback during registry pings.

This heavily borrows code from net/dial.go which implements this same
kind of race for dual stack DNS.

Rather than waiting for the initial "https" ping to time out completely
before attempting to use "http", we will instead start a second fallback
ping after 300ms and return whichever response comes back first.

This partially reverts the portion of #1165 that reduced the dial
timeout to workaround this issue.

Also, drop unused parseChallenge to appease the linter.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants