update documentation for content-flow #10203
Conversation
|
Hi @deitch. Thanks for your PR. I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
docs/content-flow.md
Outdated
| @@ -352,7 +353,8 @@ they aren't there, they won't be removed. | |||
| ### Snapshots | |||
|
|
|||
| The content in the content store is immutable, but also in formats that often are unusable. For example, | |||
| most container layers are in a tar-gzip format. One cannot simply mount a tar-gzip file. Even if one could, | |||
| most container layers are in a tar-gzip format. One cannot simply mount a tar-gzip file. In addition, they might not only be new | |||
There was a problem hiding this comment.
The OCI Image Spec does explicitly say that for the layer media type, modifications and additions are represented the same way (https://github.com/opencontainers/image-spec/blob/v1.1.0/layer.md#change-types). So while they can be modifications, they're represented as the entire new file to replace the previous file.
Is this clarification in preparation for a new media type that actually represents changes rather than the full replacement content? If not, does this accidentally make that less clear?
There was a problem hiding this comment.
while they can be modifications, they're represented as the entire new file to replace the previous file.
That is a valid point. What I wrote can confuse people. I will change that.
Is this clarification in preparation for a new media type that actually represents changes rather than the full replacement content? If not, does this accidentally make that less clear?
No, it isn't. I have interest in a new media type, but it is for my own specific use case, not something that I will attempt to upstream. That has nothing to do with this paragraph.
The entire purpose of this paragraph is to explain why we need those committed and then active snapshots at all. Someone might come to this fresh and think, "I have all of the content in the containerd content store as blobs. Why does it not just create the overlay right on top of them?"
This explains that these layers are the content, but possibly unusable directly (due to immutability and their format). This is more of a "storage format" and less of a "mount and use format."
There was a problem hiding this comment.
I reworked this paragraph. Have a look?
Signed-off-by: Avi Deitcher <avi@deitcher.net>
deitch
force-pushed
the
content-flow-with-snapshot-updates
branch
from
a2f287e
to
8ca7b11
Compare
Per the discussion in slack with @Kern-- ; once he shared the info, let's capture it and make it broadly available.