e2e: cover the firecracker rolling update - #215
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Firecracker gets rolling-update coverage — the last major behaviour it shared with Cloud Hypervisor but never exercised.
What was added
t15_rolling_update.sh— re-applying a manifest with health checks must take the rolling path: a second deployment row appears withparent_idpointing back at the first, the parent is eventually reaped, and exactly one microVM remains.The
parent_idmachinery is runtime-agnostic, but it had never run against Firecracker, and it matters more here than on containers. A rollout boots a second microVM while the first still holds its TAP, its rootfs copy and its API socket. If the parent is not torn down once the child is up, every redeploy leaks a VM's worth of host resources — and nothing would have caught it.Beyond CH's equivalent (
t10_rolling_update), this also asserts the teardown side: that the parent row reachesdeletedand that the socket count returns to one rather than staying at two.Verification
Run locally against real microVMs. Observed: v1 boots, re-apply produces a child linked by
parent_id, the parent is reaped, one VM remains, and deleting the child leaves nothing behind.Firecracker e2e coverage: 9 → 15 across this session (#213, #214, this one).