Closed dbaldy closed 1 year ago
@simondeziel looks like the pylxd tests are failing due to the python version available in Github Actions. Could you send a PR to align things with supported version?
Merging #526 (6e609b6) into master (efab4c4) will increase coverage by
0.00%
. The diff coverage is100.00%
.:exclamation: Current head 6e609b6 differs from pull request most recent head 9e73391. Consider uploading reports for the commit 9e73391 to get more accurate results
@@ Coverage Diff @@
## master #526 +/- ##
=======================================
Coverage 97.03% 97.03%
=======================================
Files 56 56
Lines 4250 4252 +2
=======================================
+ Hits 4124 4126 +2
Misses 126 126
Impacted Files | Coverage Δ | |
---|---|---|
pylxd/models/instance.py | 95.77% <100.00%> (+0.02%) |
:arrow_up: |
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more
@stgraber @simondeziel have a look at https://github.com/lxc/pylxd/pull/527
thanks!
@dbaldy could you rebase your PR on master so we can get a test run following @fliiiix's fix?
@stgraber done
@dbaldy sorry, the GH action config had a typo on our side. Could you rebase it again?
@stgraber done
Thanks @dbaldy, @stgraber & @simondeziel for the effort
can we get this fix in a release?
A release for this would be great.
Closes #523
LXD considers the socket in non-interactive mode as a pipe, much more than a Web socket. Indeed, once the command is finished executing, LXD "unpolitely" closes the sockets on its side without having the normal conversational close expected for Web Sockets (see 5.5.1).
As the
pylxd
client was not informed, it tries torecv
on a closed socket, hence raising aConnectionResetError
. It is arguable who is at fault here, whether the implementation done onLXD
's side is invalid, or if thews4py
isn't defensive enough with a Web socket being treated as a pipe and not a bi-directional stream by the counterpart.This merge request suppresses the exception traceback, as in our experience it never happened that the socket was closed by the server in the middle of an execution without the command running successfully, however it appears systematically on successful execution of the command, which is extremely misleading.