-
Notifications
You must be signed in to change notification settings - Fork 15
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
Tests for disconnections during lxc exec
#284
Tests for disconnections during lxc exec
#284
Conversation
There are too many commits in here, @hamistao did something went wrong when pushing/opening the PR? |
f5ae15b
to
7a05cb3
Compare
9a612c8
to
53d9683
Compare
@simondeziel Yes I messed up my rebase, I should have opened this as a draft. Sorry about that. |
0a38f38
to
ec1e9dc
Compare
@simondeziel Fixed, this should not be merged yet since the VM fix tested here is not in LXD yet, but feel free to take a look whenever you can. |
No worries at all! |
ec1e9dc
to
2c8a847
Compare
2c8a847
to
c96f034
Compare
@simondeziel happy with this? |
42c07fc
to
0ba22da
Compare
0ba22da
to
2146528
Compare
@simondeziel This is ready for another review. I believe the failing tests are unrelated to these changes since all modified files' tests pass. |
2f00d90
to
707e85c
Compare
@simondeziel I keep getting a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://github.com/canonical/lxd-ci/actions/runs/10885376800/job/30202865680?pr=284 taking ~2h feels like a bug as I'd expect lxc stop
to timeout before that long, no?
That said, I think the context deadline bit might be addressed by waiting for complete boot before doing the shutdown.
tests/vm
Outdated
|
||
# Launch test instance | ||
lxc launch "${IMAGE}" vm1 --vm | ||
waitInstanceReady vm1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
waitInstanceReady vm1 | |
waitInstanceBooted vm1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
taking ~2h feels like a bug as I'd expect lxc stop to timeout before that long, no?
I think the timeout is indeed very long so this should be expected
That said, I think the context deadline bit might be addressed by waiting for complete boot before doing the shutdown.
Yeah, that makes sense, thanks!
tests/vm
Outdated
echo "==> Test cleanly stopping a VM" | ||
lxc stop vm1 | ||
lxc start vm1 | ||
waitInstanceReady vm1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
waitInstanceReady vm1 | |
waitInstanceBooted vm1 |
707e85c
to
b196f12
Compare
@simondeziel This is ready again |
Signed-off-by: hamistao <[email protected]>
Signed-off-by: hamistao <[email protected]>
Signed-off-by: hamistao <[email protected]>
Signed-off-by: hamistao <[email protected]>
Signed-off-by: hamistao <[email protected]>
Signed-off-by: hamistao <[email protected]>
b196f12
to
8e4438c
Compare
As was discussed with @mihalicyn If containers are stopped gracefully, the exit code can be 129(SIGHUP) or 143(SIGTERM) depending on the signal used, both results have been seen and make sense. If forcefully stopping a container the exit code is always 137 (SIGKILL). For VMs, the exit code was standardized as 129 for all cases by #13875 (not merged yet).
In its current state, this PR only adds tests for forcefully stopping containers and VMs.