Skip to content

Define a new remote.DefaultTransport.#1165

Merged
imjasonh merged 4 commits intogoogle:mainfrom
mattmoor:switch-to-custom-transport
Nov 11, 2021
Merged

Define a new remote.DefaultTransport.#1165
imjasonh merged 4 commits intogoogle:mainfrom
mattmoor:switch-to-custom-transport

Conversation

@mattmoor
Copy link
Copy Markdown
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
Copy Markdown

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
Copy Markdown
Collaborator Author

mattmoor commented Nov 4, 2021

@googlebot I fixed it.

@google-cla
Copy link
Copy Markdown

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
Copy Markdown
Collaborator Author

mattmoor commented Nov 4, 2021

@googlebot I fixed it.

@google-cla
Copy link
Copy Markdown

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
Copy Markdown
Collaborator Author

mattmoor commented Nov 4, 2021

@googlebot I fixed it.

@google-cla
Copy link
Copy Markdown

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
Copy Markdown
Collaborator Author

mattmoor commented Nov 4, 2021

image

omg I hate you CLA bot

@mattmoor mattmoor force-pushed the switch-to-custom-transport branch from 31bbe05 to 4c81250 Compare November 4, 2021 23:56
@mattmoor
Copy link
Copy Markdown
Collaborator Author

mattmoor commented Nov 4, 2021

Switched to the old email 🙃

@mattmoor mattmoor force-pushed the switch-to-custom-transport branch from 4c81250 to 13cab84 Compare November 5, 2021 00:04
@mattmoor
Copy link
Copy Markdown
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
Copy Markdown

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
Copy Markdown
Contributor

@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.

Comment thread pkg/gcrane/copy_test.go
@imjasonh
Copy link
Copy Markdown
Contributor

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

@mattmoor
Copy link
Copy Markdown
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
```
@mattmoor mattmoor force-pushed the switch-to-custom-transport branch from 13cab84 to 7df8286 Compare November 10, 2021 22:44
Comment thread cmd/crane/cmd/root.go Outdated
@imjasonh imjasonh merged commit 7a6ee45 into google:main Nov 11, 2021
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.

4 participants