overlay: Extend documentation comment for layout#1933
overlay: Extend documentation comment for layout#1933cgwalters wants to merge 1 commit intocontainers:mainfrom
Conversation
cgwalters
force-pushed
the
doc-architecture
branch
from
4ac5364 to
eff221a
Compare
|
BTW, feel free to (please do) just force push updates to this PR to add/fix things. |
mtrmac
left a comment
mtrmac
left a comment
There was a problem hiding this comment.
Just some quick comments because I glanced at the PR list…
One vague thought: that there are two very different audiences who might read this: support investigators who need to understand some specific broken filesystem state, and developers who need to understand all possible combinations and rules and invariants.
| ## DESCRIPTION | ||
| The *containers/storage* library manages the following object types: | ||
|
|
||
| - layer: A filesystem tree, along with metadata |
There was a problem hiding this comment.
… organized in, and optimized for, a tree of parent/child links, where a single “layer” may either serve as a complete filesystem tree, or a difference from the parent.
| - image: A reference to a layer, along with metadata | ||
| - container: A layer whose parent is an image |
There was a problem hiding this comment.
These feel a bit too reductionist to me.
The important thing about images is that, unlike, layers, users frequently with deal with them directly; that they have human-usable names; and that they are nevertheless deduplicated.
The important thing about containers is… ? That the top layer is read-write? That a lot of the metadata is actually not in c/storage but in Podman’s / CRI-O’s data? Also, technically the parent of the container’s layer is still a layer.
| - image: A reference to a layer, along with metadata | ||
| - container: A layer whose parent is an image | ||
|
|
||
| ## Layer storage |
There was a problem hiding this comment.
Discusssion of graph drivers?
There was a problem hiding this comment.
Would make sense to add in theory but I personally don't care much since I think we're in a place where there is only the overlay driver that matters, right?
Let's expand the existing doc comment, as it's really useful to understand the implementation in order to debug or improve things. We also clearly say first that these are implementation details. Signed-off-by: Colin Walters <walters@verbum.org>
cgwalters
force-pushed
the
doc-architecture
branch
from
eff221a to
93e5917
Compare
cgwalters
changed the title
containers-storage-architecture.md
|
@giuseppe PTAL |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cgwalters, rhatdan The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
LGTM |
|
This one isn't urgent, I think we can just leave it as draft and I may circle back to it later. No need for others to dive in for review now, we have more important things. |
|
Hi, and thank you for your contribution! We’ve recently migrated this repository into a new monorepo: containers/container-libs along with other repositories As part of this migration, this repository is no longer accepting new Pull-Requests and therefore this Pull-Request is being closed. Thank you very much for your contribution. We would appreciate your continued help in migrating this PR to the new container-libs repository. Please let us know if you are facing any issues. You can read more about the migration and the reasoning behind it in our blog post: Upcoming migration of three containers repositories to monorepo. Thanks again for your work and for supporting the containers ecosystem! |
4 participants
Let's expand the existing doc comment, as it's really
useful to understand the implementation in order to
debug or improve things.
We also clearly say first that these are implementation details.
Signed-off-by: Colin Walters walters@verbum.org