config,storage: support populating directories from archives #1498
Conversation
|
Thanks for the detailed PR. I think this is worth considering. I won't have a chance to do a detailed review for some weeks, but a few initial thoughts:
|
Snaipe
force-pushed
the
feature/archives
branch
from
7393034 to
0399712
Compare
|
Thanks for the early feedback, I've addressed your points about conflict validation and added a test to ensure it, and added some documentation around what exactly is being supported. |
This allows some schema types to specify a key prefix for which keys matching said prefix should conflict. This is used by a subsequent commit where a directory is populated from an archive, and any file, directory, or link whose path is under the original directory should conflict.
Tarballs are ubiquitous as a binary release format, and without any builtin ability to fetch, validate, and extract them, we are left with half-baked hacks to do all of this from the confines of a oneshot systemd service, or worse, extracting and providing the entirety of the archive contents as files and directory entries in the ignition config, resulting in very large json documents. Let's not do this. Instead, this commit formalizes the use of archives via adding a new (optional) "contents" key under a directory entry. This new contents key is identical in function as its eponymous version in the "files" entries, except that it incorporates a new "archive" subkey to specify the archive format rather than guessing with heuristics. Today, only "archive": "tar" is supported, though this commit is structured to allow the addition of other archive types if needed.
Snaipe
force-pushed
the
feature/archives
branch
from
0399712 to
4fdf6de
Compare
|
Worth noting here that https://github.com/coreos/enhancements/blob/main/os/coreos-layering.md AKA https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable is basically saying that we already have a way to version, mirror, manage, sign tarballs and use them to ship both binaries and application and OS configuration - that's what OCI/Docker container images are. |
|
Not all Linux distros that use Ignition also use ostree. For some of the ones that do, discussion is still ongoing about when layering will be the recommended customization flow and when it won't, e.g. coreos/fedora-coreos-tracker#1219. So, layering isn't a full substitute for this PR. |
|
Yes, though the larger point I was trying to make here is about the overlap between Ignition fetching raw tarballs and container images. ostree isn't a requirement for the "boot a container" model, just one implementation. In fact I consider hiding ostree to be a key goal of that effort. For example, I could also imagine that instead of this, Ignition could learn to unpack container images (e.g. One great example of a specific problem one runs into quickly when growing from Ignition's base of "configuration" to shipping code around is multi-arch support. OCI already has that problem solved. Now of course one can switch to generating Ignition fragments and having different e.g. So again my point here is I think both ostree and Ignition have problems that are best solved using container tooling which is already what our users are familiar with. |
|
I don't think this PR precludes incorporating some way to unpack container images into the rootfs, but the reason why I've made this PR is that it's immediately useful to us without needing to include a docker registry as part of bootstrapping the cluster that hosts our docker registry. In contrast, downloading a tarball over HTTP is probably as simple as you can get, and just requires an HTTP server (which we already have as far as bootstrapping is concerned since we configure HTTP boot on most of our cluster machines) |
|
I understand. Don't get me wrong, I'm not against this PR. (To be clear: I'm also not an Ignition maintainer)
Yes, though it's also entirely possible to implement the registry API with a static webserver: https://github.com/NicolasT/static-container-registry (There may be better examples of this, but it's really just a bit of JSON and tarballs...that's all OCI is) |
|
Any news on this? @bgilbert |
|
Thanks for your work on this PR. I won't be able to get back to this, unfortunately, but hopefully one of the other folks on the team can take a look. |
Tarballs are ubiquitous as a binary release format, and without any builtin ability to fetch, validate, and extract them, we are left with half-baked hacks to do all of this from the confines of a oneshot systemd service, or worse, extracting and providing the entirety of the archive contents as files and directory entries in the ignition config, resulting in very large json documents.
Let's not do this. Instead, this commit formalizes the use of archives via adding a new (optional) "contents" key under a directory entry.
This new contents key is identical in function as its eponymous version in the "files" entries, except that it incorporates a new "archive" subkey to specify the archive format rather than guessing with heuristics. Today, only "archive": "tar" is supported, though this commit is structured to allow the addition of other archive types if needed.