dbus: Remove the upper limit on try timeout (LP: #1967084) #271
Conversation
Codecov Report
@@ Coverage Diff @@
## main #271 +/- ##
=======================================
Coverage 99.07% 99.07%
=======================================
Files 61 61
Lines 10864 10864
=======================================
Hits 10764 10764
Misses 100 100
Continue to review full report at Codecov.
|
Also, increase the default to 10s. If the caller sees fit to specifiy a 30s timeout for their try call, it stands to reason to respect that decision, as they (probably) know better. This issue came up in the Core testsuite, where the netplan configuration step failed because `netplan try` took 6s, cf LP: #1967084. Their DBus call specifies a timeout of 300s, but the call failed after a "relatively short time", which was this internal timeout. Note that the mere fact that `netplan try` takes more than 5s on such a simple configuration is probably due to the following patch: https://git.launchpad.net/ubuntu/+source/netplan.io/tree/debian/patches/0006-cli-apply-give-some-extra-time-for-networkctl-reload.patch?h=applied/ubuntu/focal-updates Since the bridge is empty, it might be in a "configuring" state forever. Granted, that's not something one would do on production systems, however creating an empty bridge interface is routinely done in test suites, including our own.
schopin-pro
force-pushed
the
dbus-timeout-fix
branch
from
1fdef02
to
c72bf8c
Compare
|
After this is merged, I'm thinking of cherry-picking this fix and including it in the ubuntu-image PPA used by the coreXX builds. But this depends on the severity - if @mvo5 thinks it's not needed, then we can just wait for this to go through the usual SRU route or the root cause being fully identified. |
|
Thanks, this looks fine. Let's not forge/ignoret the other findings in LP: 1967084 though after merging this, I think there is more to this than just increasing the timeout :) (either on the snapd or the netplan side, a bit unclear to me at this point) |
Also, increase the default to 10s.
If the caller sees fit to specifiy a 30s timeout for their try call, it
stands to reason to respect that decision, as they (probably) know
better.
This issue came up in the Core testsuite, where the netplan
configuration step failed because
netplan trytook 6s, cfLP: #1967084. Their DBus call specifies a timeout of 300s, but the call
failed after a "relatively short time", which was this internal timeout.
Note that the mere fact that
netplan trytakes more than 5s on such asimple configuration is probably due to the following patch:
https://git.launchpad.net/ubuntu/+source/netplan.io/tree/debian/patches/0006-cli-apply-give-some-extra-time-for-networkctl-reload.patch?h=applied/ubuntu/focal-updates
Since the bridge is empty, it might be in a "configuring" state forever.
Granted, that's not something one would do on production systems,
however creating an empty bridge interface is routinely done in test
suites, including our own.
Checklist
make checksuccessfully.make check-coverage).