Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Docs]: More Differentiation between save/load and import/export #22155

Open
stellarpower opened this issue Mar 25, 2024 · 4 comments
Open

[Docs]: More Differentiation between save/load and import/export #22155

stellarpower opened this issue Mar 25, 2024 · 4 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. stale-issue

Comments

@stellarpower
Copy link
Contributor

stellarpower commented Mar 25, 2024

Feature request description

I find the documentation is a bit sparse about the differences between saving and loading images, and exporting and importing containers. From the wording, it implies to me that the main difference is that save/load are used for images, export is used for containers. However, if I understand correctly:

  • save/load save an image using all the layers, to an OCI/etc. format
  • export/import just use regular tarballs of the container's filesystem, that I could extract and have a look at. Layers are therefore not preserved.
  • export creates the full tarball, not only changes that have occurred over the top of the last image layer (?)
  • Export works on containers, but import will then create an image from this(?)

For example:

The image of the container exported by podman export can be imported by podman import. To export image(s) with parent layers, use podman save.
It's not totally clear to me whether the emphasis here is on the fact that the parent layers are included when saveing, or on the fact that it is used on images, rather than containers.

I think a few sentences in the documentation for all four commands more clearly differentiating the use of each command pair and contrasting when you would use which would be really useful.

As an aside, perhaps a command that could do a more full system migration might be useful. I had to system reset to ensure I got off the FUSE drivers and start again with kernel namespace mounting, so my reason for needing this is trying to get myself set back up again to where I was. I somewhat expected export to export the full container, but it seems it may be best to commit the running containers and then change the create command from inspecting them in order to use the new image with any working changes. EDIT: I guess ihs may be what checkpoint does; I'm running rootless so didn't have that option.

Suggest potential solution

No response

Have you considered any alternatives?

No response

Additional context

No response

@stellarpower stellarpower added the kind/feature Categorizes issue or PR as related to a new feature. label Mar 25, 2024
@baude
Copy link
Member

baude commented Mar 25, 2024

@stellarpower would you be willing to submit a PR for the changes you think are needed?

@stellarpower
Copy link
Contributor Author

Potentially, although I'm not totally sure if my understanding above is correct to start with.

@mheon
Copy link
Member

mheon commented Mar 26, 2024

Your understanding is correct. Save/load work about the way you'd expect (put an existing image in an archive format so you can move it around easily). Import and export work with containers, not images, and as such are a lot more complicated. We do not provide a way to turn an archive directly into a container, for one, so import creates images. Export throws everything in a tarball, no layering, which has some applications, but honestly in most cases podman commit + podman save on that image feels more correct...

Copy link

A friendly reminder that this issue had no activity for 30 days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. stale-issue
Projects
None yet
Development

No branches or pull requests

3 participants