Erofs changes roadmap

[jiria]

Merge Checklist

• Followed patch format from upstream recommendation: https://github.com/kata-containers/community/blob/main/CONTRIBUTING.md#patch-format
• Included a single commit in a given PR - at least unless there are related commits and each makes sense as a change on its own.
• Merged using "create a merge commit" rather than "squash and merge" (or similar)
• genPolicy only: Builds on Windows
• genPolicy only: Updated sample YAMLs' policy annotations, if applicable

Summary

Work in progress doc to share with containerd and notation communities.

Associated issues

Links to CVEs

Test Methodology

[miz060]

LGTM. Minor comments:
It might be better to make it clear that we want to introduce this as an optional feature through erofs-snapshotter.
The current objective can be interpreted as adding it as a general new feature.

[cpuguy83]

I think this is easier said than done.
containerd will need to be updated not only to understand OS features but likely to look for a best/most-desirable match in the list rather than a first match. Then these entries will need to come after the "legacy" ones for an image to be backwards compatible with runtimes that don't support this matching.

The future of os.features also seems somewhat dubious, though I think this is a decent/OK use for it.

[cpuguy83]

Really, its not clear to me right now how we'll end up doing these sorts of things natively as part of the containerd pull pipeline outside of having support for a different image type.

[jiria]

OS features was something that Derek mentioned on the call. Internally, we have discussed few other mechanisms for this: 1) extend the attributes used for selection of the manifest from index past the OS and architecture, 2) support equivalent of HTTP Accept header (probably far fetched), 3) construct the layer in a way that it can be interpreted as a tar, but have additional data appended at the end.

Please let me know if any of these make more sense to you and I can either change or extend the text.

[cpuguy83]

If people need to associate keys anyway, why not require these artifacts to be in the registry as well and skip on-the-fly generation?

[jiria]

From our perspective, we only care about the registry based solution. But the erofs-snapshotter already has logic for on the node generation of both the erofs blobs and the dm-verity merkle tree, and so instead of keeping that as a separate flow, it felt nice to be able to integrate it as a fallback mechanism.

[cpuguy83]

How will these images be built and published? ie. what tooling is available to deal with this?

[jiria]

At the moment, you can do everything by using the tar.gz as an input and processing it through mkfs.erofs (erofs-utils) and veritysetup. We are planning to simplify this, but I would envision that build-kit can support this as well, and possibly others. What would be the good set to target from your perspective?

[jiria]

In addition, I will comment below the issue with this snippet, to address some points from the community call:

Hello Derek,

Wanted to provide additional context based on the conversation from the last community call:

• One thing I forgot the mention during the call, the idea of using the referrers for the Milestone 2 is so that we don't have to force all publishers to update their build setup. Instead, we can rely on the registry to publish these artifacts on behalf of the publishers, which will help us drive early adoption.
• Connected to that, we could leverage separate tags for the tar index and Merkle tree for the Milestone 2. The desire to leverage the referrers is so that we could, in theory at least, have containerd prefetch these for us, to reduce the cold startup latency. Do you think that something similar could be accomplished if we just tag these additional artifacts separately?

That said, I think we all agreed on the Milestone 3. Would love to get more of your thoughts on the Milestone 2 as well.