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

Hardcoded timeout in updater.DownloadTarget #660

Open
eikenb opened this issue Dec 4, 2024 · 9 comments
Open

Hardcoded timeout in updater.DownloadTarget #660

eikenb opened this issue Dec 4, 2024 · 9 comments
Assignees
Labels

Comments

@eikenb
Copy link

eikenb commented Dec 4, 2024

data, err := update.cfg.Fetcher.DownloadFile(fullURL, targetFile.Length, time.Second*15)

We're hitting the timeout above when downloading files using the updater and want to raise it. Maybe this should be passed in as a parameter or added to the UpdaterConfig? Our current workaround is a re-implementation of the DownloadTarget() function that lets us set that value.

@rdimitrov
Copy link
Contributor

hey, @eikenb 👋

Thanks for the raising this 👍 So far we haven't had anyone else raise that 15 seconds are not enough to download a target, but I do see how hardcoding it can become an issue (big targets, slow network, etc) 👍

I've briefly checked the specification and there's no explicit mentioning of it, so it's up to the implementations to set this accordingly. That said I agree it's fair to make this configurable 👍

We'll add it to the project planning and we'll try to include in the next release. Of course we'll be more than happy to welcome a PR in case you already have something on your side 🙌 That would make things move up much faster.

@rdimitrov rdimitrov added enhancement help wanted good first issue go Pull requests that update Go code labels Dec 9, 2024
@sureshkrishnan-v
Copy link

Hi, I’d like to work on this issue as a first-time contributor—could you confirm if it’s available and share any guidelines?

@rdimitrov
Copy link
Contributor

@sureshkrishnan-v - Thanks for volunteering! Let's see in case @eikenb already have something prepared there and if not you'll be safe to proceed 👍

As for the guidelines the idea is to make this timeout configurable and not hardcoded to 15s. If it's not set during initialisation, we can safely default to 15 second, but otherwise we should use the value set in the configuration. Does that make sense?

@sureshkrishnan-v
Copy link

Ok, the timeout hardcoded to 15s needs to be configurable else it defaults to 15s am I right? and need to know how can I get time from updaterconfig struct will it be set at initialisation time ?

@rdimitrov
Copy link
Contributor

Yes, it should be available through config.UpdaterConfig 👍

But again, I would wait to see in case @eikenb has anything already prepared so we don't duplicate the same work twice 👍

@sureshkrishnan-v
Copy link

ok i will wait

@eikenb
Copy link
Author

eikenb commented Dec 11, 2024

@rdimitrov @sureshkrishnan-v ... Sorry for the delayed response. I don't have time to write anything for this currently. So no blocker on my end to letting @sureshkrishnan-v work on it.

Thanks for the consideration and great to hear it will be addressed.

@rdimitrov
Copy link
Contributor

Thanks for the reply, @eikenb 🙏

@sureshkrishnan-v - I'll assign it to you 👍

@rdimitrov rdimitrov moved this from Release backlog to In Progress in go-tuf/v2 project planning Dec 13, 2024
@sureshkrishnan-v
Copy link

I believe I have completed the task as specified. Can I proceed with a PR? #660

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: In Progress
Development

No branches or pull requests

3 participants