moby: Checkpoint dir option is broken in 17.06 when creating checkpoints

With 17.03.0~ce-0~ubuntu-xenial:

docker checkpoint create --checkpoint-dir=/some/path container_name checkpoint_name stores checkpoint data in /some/path/checkpoint_name

With 17.06.1~ce-0~ubuntu:

docker checkpoint create --checkpoint-dir=/some/path container_name checkpoint_name stores checkpoint data in /some/path/CONTAINER_ID/checkpoints/checkpoint_name

Looks like this commit/line broke it https://github.com/moby/moby/commit/d400518f4d139733f1f5b9333f493b1f9d76b8a1#diff-d2fd8e9feab75f193a7d19493831c1f1R24

Or was it intentional?

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 1
  • Comments: 29 (25 by maintainers)

Commits related to this issue

Most upvoted comments

@phil294 checkpoint/restore is an experimental feature, while we do generally try to not break experimental features breakages can happen and should even be expected. Also clearly there is not enough testing around the feature since there are multiple breakages.

We need to evaluate if --checkpoint-dir makes sense. I know people are using this for some really cool cases so it would be good to make sure this is covered with whatever we decide to do. Under containerd 1.0 we can treat checkpoints as a special kind of image which opens up the door for a lot of interesting workflows.

@kolyshkin But the output you posted is exactly what the wrong behaviour is. The right behaviour is to have checkpoint data in /tmp/x/cpt1.

Guys, I’m a bit surprised a breaking change got into release version just because someone alone decided it would be better this way, but can we make sure now we’re all on the same page and the issue won’t get accidentally closed or anything.

Yes sure will do.

@dattatrayakumbhar Can you please open a PR to revert the behavior of --checkpoint-dir? It seems that the current behavior of --checkpoint-dir deviates from its original purpose, and it’s breaking users.