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

Backup and restore all HostConfig settings #22

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

andrewleech
Copy link

This ensures new container has all the existing settings like bind mount paths, RestartPolicy, Privileged, etc.

This ensures new container has all the existing settings like bind mount paths, RestartPolicy, Privileged, etc.
@muesli
Copy link
Owner

muesli commented Apr 28, 2021

This looks good and should probably be the default, but I wonder if we shouldn't allow to optionally turn this off. I'm a bit worried there may be various situations where the original host config doesn't fully apply to the new container. We could look at the list of HostConfig members and identify problematic candidates.

@andrewleech
Copy link
Author

Yeah that's a good point. While there are a lot of keys I ended up needing in HostConfig, there are even more I never even tried to figure out the function of. There probably are a likely set of keys that don't make sense to store, especially for cases where you're restoring on a different host.

I think the safest option is to backup all of these keys (then there's no regret later from not having information you find you need), but then having a way to choose / filter what gets restored, or at least having a pre-set list of keys to restore that should work in most/all cases.

@muesli
Copy link
Owner

muesli commented Apr 30, 2021

I think the safest option is to backup all of these keys (then there's no regret later from not having information you find you need), but then having a way to choose / filter what gets restored, or at least having a pre-set list of keys to restore that should work in most/all cases.

I fully agree!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants