task: allow to specify namespaces which are restored externally#2425
task: allow to specify namespaces which are restored externally#2425crosbymichael merged 1 commit intocontainerd:masterfrom
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2425 +/- ##
=========================================
+ Coverage 44.73% 45% +0.27%
=========================================
Files 93 92 -1
Lines 9501 9412 -89
=========================================
- Hits 4250 4236 -14
+ Misses 4566 4493 -73
+ Partials 685 683 -2
Continue to review full report at Codecov.
|
|
Cc: @kolyshkin |
There was a problem hiding this comment.
So, why are we using interface{} type for CheckpointTaskInfo.Options field? Wouldn't it be cleaner for it to be of runctypes.CheckpointOptions? I.e. have
// TaskInfo sets options for task creation
type TaskInfo struct {
// Checkpoint is the Descriptor for an existing checkpoint that can be used
// to restore a task's runtime and memory state
Checkpoint *types.Descriptor
// RootFS is a list of mounts to use as the task's root filesystem
RootFS []mount.Mount
// Options hold runtime specific settings for task creation
Options runctypes.CheckpointOptions
}At least this way we'll avoid doing tricks like the one in here, as well as typecasting it every time.
|
Notes
|
There was a problem hiding this comment.
The word "externally" here means "external to criu". I would change it to say
... a namespace which properties are not to be restored by criu
Also maybe add that this corresponds to criu --empty-ns option.
There was a problem hiding this comment.
It doesn't matter what tools are used for C/R
Here we have a few tests: |
There was a problem hiding this comment.
Yes, we can. @kolyshkin and I could not understand this trick. Could you explain its idea?
There was a problem hiding this comment.
@crosbymichael from my perspective having interface{} here makes the rest of code unnecessary complicated (with extra casts and type checks). Can you elaborate on why you want this to be of interface{} type? I could (theoretically) anticipate a C/R engine other than CRIU but practically this is too far in the future I'd care for now.
There was a problem hiding this comment.
https://github.com/google/gvisor (runsc) also has checkpoint/restore capability, and we are actively working on hooking it up to docker (i.e. fixing moby and stuff) as well. See moby/moby#37360.
So there already is another C/R engine.
69278c8 to
bf848ff
Compare
Signed-off-by: Andrei Vagin <[email protected]>
|
Is there anything needed for this PR to go through? |
|
LGTM |
|
Hi , @avagin , from your example fix commit, you write that Could you tell me why criu cannot dump and restore net ns, thanks. |
|
@Ace-Tang criu can dump/restore netns, but it should not in this very case. |
|
Thanks for your reply, @kolyshkin |
Currently, C/R in https://github.com/moby/moby is completely broken. This pr is required to fix it.
Here is an example of how entirely fix looks like:
avagin/docker-ce@911c89f