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

Add API/support for waiting on network #259

Closed
cgwalters opened this issue Aug 2, 2022 · 2 comments · Fixed by #264
Closed

Add API/support for waiting on network #259

cgwalters opened this issue Aug 2, 2022 · 2 comments · Fixed by #264

Comments

@cgwalters
Copy link
Contributor

Breaking this out from coreos/rpm-ostree#3096

Basically I'm thinking we could add something like

lr_handle_setopt(priv->repo_handle, error, LRO_NETWORK_WAIT, TRUE);

This would end up parsing the URL baseurl or metalink and using https://developer-old.gnome.org/gio/2.68/GNetworkMonitor.html to wait until the URL (host) was reachable.

A big question in my mind is - could we actually enable this by default? It's tempting to try, but the "blast radius" seems large too. So perhaps better to opt-in to start at least.

There's someone on the CoreOS team interested in working on this potentially; does this proposal make sense to you?

@kontura
Copy link
Contributor

kontura commented Aug 8, 2022

If I understand correctly this would wait for the clients network interfaces. So for example when a workstation is starting it is possible to run dnf before the network is fully setup and with this change it would wait instead of failing.

This would make sense for us, we even have a fix for such a problem with dnf-automatic: rpm-software-management/dnf#1616

I also think that it shouldn't be such a problem if it was ON by default. For dnf perhaps we could make it a default in dnf5 and keep it as opt-in in dnf4.

@cgwalters
Copy link
Contributor Author

If I understand correctly this would wait for the clients network interfaces. So for example when a workstation is starting it is possible to run dnf before the network is fully setup and with this change it would wait instead of failing.

Right.

This would make sense for us, we even have a fix for such a problem with dnf-automatic: rpm-software-management/dnf#1616

Yeah, using GNetworkMonitor is better than a polling approach - it will avoid wasting CPU/energy.

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 a pull request may close this issue.

2 participants