KEP-2008: Provide details about additional checkpoint/restore use cases

[adrianreber]

• One-line PR description: Provide details about additional checkpoint/restore use cases

• Issue link: Forensic Container Checkpointing #2008

[k8s-ci-robot]

Hi @adrianreber. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions 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.

[bart0sh]

/ok-to-test

[adrianreber]

@mikebrow as discussed I tried to update the KEP with different possible use cases. PTAL.

[mikebrow]

additional future stories read well... not obvious if they are to be officially supported cases or additional will not be supported cases

Did you want to add more details to the forensics story? Including a scenario how/why kubelet needs to provide garbage collection / manage which are garbage collected..

Similarly, for cli enablement kubernetes/kubernetes#120898 (comment) do you want to go over the expansion of this kubelet endpoint to cover kubectl enablement, mention how a user would use kubectl in these stories.. and probably add the management (manual and automatic .. CRUD) options?

[adrianreber]

@mikebrow Thanks

additional future stories read well... not obvious if they are to be officially supported cases or additional will not be supported cases

Added a paragraph that future stories currently already can be used with the existing implementation, but that additional support for a more user friendly implementations can be implemented. Not very concrete, but acknowledged that additional support can be added.

Did you want to add more details to the forensics story? Including a scenario how/why kubelet needs to provide garbage collection / manage which are garbage collected..

I added a paragraph about checkpoint archive management. That is might be different depending on the use case but I gave three examples how it could be implemented.

Similarly, for cli enablement kubernetes/kubernetes#120898 (comment) do you want to go over the expansion of this kubelet endpoint to cover kubectl enablement, mention how a user would use kubectl in these stories.. and probably add the management (manual and automatic .. CRUD) options?

I mentioned my kubectl PR in the Future Enhancements section.

PTAL.

[adrianreber]

@rst0git Thanks for the suggestions and the patch. Applied.

[adrianreber]

@mikebrow do you have any additional comments? Any recommendations how to move this forward?

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: adrianreber
Once this PR has been reviewed and has the lgtm label, please assign mrbobbytables for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• keps/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[soltysh]

@adrianreber any particular reason this is separate from #4288, can we get both PRs merged as one?

[adrianreber]

@adrianreber any particular reason this is separate from #4288, can we get both PRs merged as one?

This is again complicated. My initial approach to get this feature in Kubernetes around 2019 was to focus on container migration. Then we came up with a much simpler way using the "Forensic Container Checkpointing" story. So we worked on that and it got merged. One of the steps to get it from Alpha to Beta at that time was at least one container engine should implement the new CRI API calls. CRI-O did.

When trying to graduate from Alpha to Beta the feedback from SIG-Node was that containerd should also implement it. From containerd's side I was told that the current KEP focussing on "Forensic Container Checkpointing" feels incomplete and all possible use cases should be described in the KEP.

So now I have a Alpha to Beta graduation KEP which depends on containerd support. containerd wants to merge the CheckpointContainer CRI implementation PR after this one here with the complete story is merged.

The Alpha to Beta graduation is full of discussions and adding additional discussions about use cases seems to complicate everything even more.

If everybody is happy with the changes of this PR I can include it in the other PR. I don't know.

[soltysh]

I'll defer to sig-node leads about that decision, it's theirs call about merging, I'm asking only from PRR review perspective.