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

[EEESUPPORT-11240] Add logging and retries to pull_cmd #62

Merged
merged 3 commits into from
Aug 26, 2024

Conversation

guyboltonking
Copy link
Member

@guyboltonking guyboltonking commented Aug 22, 2024

The retry logic required patching containerd; see guyboltonking/containerd#2 to review the patch. Commits can be reviewed in order.

@guyboltonking guyboltonking force-pushed the guy/EEESUPPORT-11240/ocitool-retries-and-logging branch from 5fef52d to 69da090 Compare August 22, 2024 16:13
@guyboltonking guyboltonking marked this pull request as ready for review August 22, 2024 16:14
Copy link
Contributor

@joneshf-dd joneshf-dd left a comment

Choose a reason for hiding this comment

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

I think this change will work to address the specific issue, so 👍🏾 from me. But I'm curious if we considered pulling in one of the retry packages and wrapping the call to image.Dispatch instead (so we don't have to maintain this patch or care which part of it is failing). Some (but not all) of the retry packages:

We should also be able to use a retry package for other calls we find to be flaky that don't already have a retry mechanism.

Similar to the 💭, this isn't blocking. Something to think about, and do whatever you think is best.

go/cmd/ocitool/pull_cmd.go Show resolved Hide resolved
@guyboltonking
Copy link
Member Author

But I'm curious if we considered pulling in one of the retry packages and wrapping the call to image.Dispatch instead (so we don't have to maintain this patch or care which part of it is failing).

I'm not sure I want to wrap all of image.Dispatch, since I only want to log and retry at the point where we know we're seeing a failure, rather than retrying higher up and risking retrying on failures that we shouldn't retry on.

I briefly looked at avast, decided it was too much to add for this one case, and was also put off by the fact I couldn't go get it:

❯ go get github.com/avast/[email protected]
go: github.com/avast/[email protected]: invalid version: go.mod has post-v4 module path "github.com/avast/retry-go/v4" at revision v4.6.0

...at which point I read about how go get behaves with respect to semver, go.mod presence, and whether the moon is gibbous, and decided to give up.

@joneshf-dd
Copy link
Contributor

joneshf-dd commented Aug 23, 2024

That's also fair (re: not potentially introducing other failures by retrying the whole process). No need to spin your wheels on it!

Re: avast/retry-go, you have to include the /v4 part at the end of the package:

$ go get github.com/avast/[email protected]
go: github.com/avast/[email protected]: invalid version: go.mod has post-v4 module path "github.com/avast/retry-go/v4" at revision v4.6.0

$ go get github.com/avast/retry-go/[email protected]
go: downloading github.com/avast/retry-go/v4 v4.6.0
go: added github.com/avast/retry-go/v4 v4.6.0

@guyboltonking guyboltonking merged commit 7fcb47e into main Aug 26, 2024
2 checks passed
@guyboltonking guyboltonking deleted the guy/EEESUPPORT-11240/ocitool-retries-and-logging branch August 26, 2024 08:25
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.

2 participants