storage: use volatile containers #4885
Conversation
|
LGTM |
|
/cc @rhatdan |
|
/retest |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: giuseppe, rhatdan, saschagrunert The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/hold actually I'm not sure about this. We rely on the container storage to cleanup CNI resources on reboot now (see #4767). Does the volatile option apply to the config.json as well (the information we'd need to restore a pod to then call CNI del)? |
|
@giuseppe This only applies to the rootfs? |
|
looking into it, I misuderstood a bit what volatile did. Still, we need to be able to restore containers on reboot (or at least call CNI del on ones we fail to restore). |
|
This will only effect the overlay storage layer, not any of the other artifacts of the container. If the system crashes some of the content in the container image could be lost, but nothing else. |
|
yes, |
|
/retest |
|
/test e2e-agnostic |
overlay supports a new mount option "volatile" that reduces I/O by ignoring fsync and syncfs requests. Enable it for CRI-O containers as they are "volatile" by nature and are not supposed to survive a reboot. Even in the case containers created by CRI-O are persistent, we already have code in place to throw away the storage if the shutdown was not clean, so they will be cleaned up in any case. Signed-off-by: Giuseppe Scrivano <[email protected]>
|
/retest |
|
/retest |
|
anything more holding this PR? |
|
/hold cancel My previous concerns are alleviated, LGTM |
|
/retest |
|
@giuseppe: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
can I've my lgtm back? :-) |
|
/lgtm |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
3 similar comments
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
overlay supports a new mount option "volatile" that reduces I/O by
ignoring fsync and syncfs requests.
Enable it for CRI-O containers as they are "volatile" by nature and
are not supposed to survive a reboot.
Even in the case containers created by CRI-O are persistent, we
already have code in place to throw away the storage if the shutdown
was not clean, so they will be cleaned up in any case.
Signed-off-by: Giuseppe Scrivano [email protected]
What type of PR is this?
/kind feature
What this PR does / why we need it:
Enable
volatilefor the overlay storage.Which issue(s) this PR fixes:
Special notes for your reviewer:
Does this PR introduce a user-facing change?