-
Notifications
You must be signed in to change notification settings - Fork 17
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
Oci manifest format of puzzlefs #55
Comments
The OCIv1 manifest format is specified at https://github.com/opencontainers/image-spec/blob/main/manifest.md . I think we should stick to something closer to that. Perhaps:
Explanation:
|
It does seem a little weird to duplicate the information in both a json format and a custom capnproto format. What's more, the notion of a |
@hallyn what do you think? |
Well, failing a good idea for an alternative, let's leave it as is for now and re-open if we come up with something. |
Now that I'm working on the stacker support for building PuzzleFS images, I think it's time to revisit this issue and the delta generation. |
Hey, sorry for the delay.
I ran into this problem a bunch with tools when I did stacker's squashfs support, and filed stuff like opencontainers/image-spec#816 in support of it. I got it all plumbed through, and hopefully did it in a way that future-proofed it for puzzlefs, so I think a new mime type is a good path forward, especially since stuff like storage and hosting (i.e. the distribution spec) makes it so that you don't have to build tooling for those parts.
I think it's reasonable in a vacuum, but you would have to teach other tools (skopeo, dist spec) about this new format, which is kind of annoying.
There are two explicit mentions of layering, descriptors and history. I think that for History, we'll still have this concept: users will build puzzlefs images by individual mutations to them ( So what's left is Descriptors, which, while called Layers in the manifest, could be "just" a list of BlobRefs. Admittedly they're not layers, but the delta is so small, and the amount of work to generate the rest of the tooling is so great, that I would lean towards just re-using the OCI spec here. Maybe we can send some clarifying PRs that "not all OCI images need be layer based" or something? Thank you for continuing to push on this, it's awesome! |
Thanks for your input, @tych0
where
When mounting the image, PuzzleFS will parse the list of layers, extract the The main advantages would be compatibilty with existing tools and decoupling the PuzzleFS merkle tree structure from the OCI Image Manifest. Did I get this right? |
Heh, I don't think I quite got it right, I had forgotten that you needed mime types for the layers. It seems like a bit of a hack, but yes, that's what I had in mind. (Is there a reason inodes is not part of rootfs?) |
I think this was the original design even when we had cbor serialization. And we do have layers in PuzzleFS right now, and that's another thing to consider when designing the OCI format of PuzzleFS. We could include the entire PuzzleFS metadata in one single capnp file, that way we'll only have |
Definitely a mistake then :).
Yeah, it's a good point. It's almost as if OCI's "layers" is just transport for bits, and we want to allow images to have more than just the OCI's version of Metadata, Config, and Layers. I suppose another option is that we could add pointers as Annotations on metadata, but then tools will not automatically transport them. IMO the way you have it above is probably the best because we can use existing tooling, even if it is slightly confusing.
that sounds reasonable to me. |
This simplifies the PuzzleFS layout by storing all the metadata information into a single metadata file. The previous layout had one manifest file which contained references to a list of metadata files, each stored separately. Relevant discussions: project-machine#55 Signed-off-by: Ariel Miculas-Trif <[email protected]>
Previously, the OCI Image Index contained a list of manifests which were referencing the PuzzleFS rootfs image, i.e. the metadata of the PuzzleFS image in Capnproto format. Now the Image Index [1] references an Image Manifest [2] and the PuzzleFS image (the PuzzleFS rootfs image together with the file chunks) is embedded into the layers field of the Image Manifest. Where PuzzleFS diverges from the Image Manifest spec is in the layers definition: our layers are not self contained images and thus they do not stack. Instead, we have a rootfs layer which stores the PuzzleFS image rootfs and multiple file chunks which contain the actual data of the filesystem. No extraction step is performed. Instead, when mounting a PuzzleFS image, the filesystem is reconstructed from the PuzzleFS metadata and the file chunks, not unlike how squashfs/erofs archives are mounted directly. See the "Inspecting a puzzlefs image" section from the README for more details about the format. The image config is an empty descriptor [3] for now, but we don't store it in blobs/sha256, which causes `skopeo copy` to fail because it doesn't find the blob referenced by the empty descriptor in the data store. This will be addressed in a subsequent commit. See project-machine#55 for more context. [1] https://github.com/opencontainers/image-spec/blob/main/image-index.md [2] https://github.com/opencontainers/image-spec/blob/main/manifest.md [3] https://github.com/opencontainers/image-spec/blob/main/manifest.md#guidance-for-an-empty-descriptor Signed-off-by: Ariel Miculas-Trif <[email protected]>
We should add a |
The current puzzlefs manifest format is as follows:
Whereas for oci v1, the manifest has the following format:
The text was updated successfully, but these errors were encountered: