Closed cgwalters closed 1 year ago
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
: https://github.com/rpm-software-management/dnf/pull/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
.
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: https://github.com/rpm-software-management/dnf/pull/1616
Yeah, using GNetworkMonitor is better than a polling approach - it will avoid wasting CPU/energy.
Breaking this out from https://github.com/coreos/rpm-ostree/issues/3096
Basically I'm thinking we could add something like
This would end up parsing the URL
baseurl
ormetalink
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?