This repository was archived by the owner on Oct 10, 2020. It is now read-only.
Stop reading/writing "install data" in /var/lib/atomic#969
Closed
cgwalters wants to merge 1 commit intoprojectatomic:masterfrom
Closed
Stop reading/writing "install data" in /var/lib/atomic#969cgwalters wants to merge 1 commit intoprojectatomic:masterfrom
cgwalters wants to merge 1 commit intoprojectatomic:masterfrom
Conversation
This reverts: projectatomic#950 See: projectatomic#966 The idea here originally was good, but we have to be a *lot* more careful in introducing data stores than this. They need "schema design", documentation, and most importantly IMO: lifecycle coupling. If I e.g. `rm -rf /var/lib/docker` (as a lot of documentation tells people to do, this install data would stick around. Similarly for deleting content directly in `/ostree/repo`. You could say that's a bug, but it'll happen. The best way to do metadata is to use the underlying store. OSTree in particular already has an API for storing metadata. Any containers we write there should use that. I'm not sure offhand if we can do something similar with Docker. But basically I don't think it's worth carrying another data store *just* to show a warning.
Member
|
This was not something invented for just a warning. This was a user-based request. We have people trying to run containers before installing them and then reporting that as a bug. The openscap image is a perfect example. We knew this implementation was going to be imperfect but it was better that doing nothing. |
Member
Author
|
OK. We can close this and return to fixing the existing implementation. |
Member
|
I'd like your ideas on how it can be improved. Prefer to work this as an issue? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This reverts: #950
See: #966
The idea here originally was good, but we have to be a lot more
careful in introducing data stores than this. They need "schema design",
documentation, and most importantly IMO: lifecycle coupling.
If I e.g.
rm -rf /var/lib/docker(as a lot of documentation tellspeople to do), this install data would stick around. Similarly
for deleting content directly in
/ostree/repo. You could saythat's a bug, but it'll happen.
The best way to do metadata is to use the underlying store. OSTree
in particular already has an API for storing metadata. Any containers
we write there should use that.
I'm not sure offhand if we can do something similar with Docker.
But basically I don't think it's worth carrying another data store
just to show a warning.