Use ostree checkout for buildroot #127
Conversation
Currently the buildroot is constructed from scratch using `mmdebstrap`. That requires knowing the exact apt sources that the branch of the OS uses. Instead, the buildroot can be created from a checkout of the ostree that's going to be used for the deployment since it already contains the appropriate apt/dpkg configuration. That changes the host requirements from `mmdebstrap` and `rsync` to the `ostree` CLI package. Ideally an `eos` container would be used rather than the bespoke `chroot` setup, but that's a bigger change for another day. https://phabricator.endlessm.com/T35019
The only use of the GPG keys is to validate the buildroot source. With `mmdebstrap` a full GPG keyring was required. However, the `ostree` `--gpg-import` option accepts individual keys and builds the remote trusted keyring on its own. Stop creating the keyring and just pass the key paths to `ostree`. After that the explicit host `gnupg` dependency is no longer required (although `ostree` internally uses `gnupg`). https://phabricator.endlessm.com/T35019
dbnicholson
force-pushed
the
T35019-ostree-buildroot
branch
from
586a5ae
to
c582949
Compare
|
I got a little worried about the buildroot checkout corrupting the ostree objects, so I added a fixup to copy the objects. It's definitely much slower, but it should be safer. It would be nice use an overlayfs or something like that. |
There was a problem hiding this comment.
This looks great. One less tool to think about, one less thing to keep in sync.
Thinking about this at a high level, and assuming R is the OSTree ref that we are trying to build an image around:
- Pull
Rto/var/cache/eos-image-builder/content/ostree/repo - Deploy
Rto/var/tmp/eos-image-builderas a mutable copy - Chroot into that mutable copy, bind-mounting
/var/cache/eos-image-builder/contentinto the chroot - In
eib_ostree, pullRinto/var/cache/eos-image-builder/content/ostree/repoa second time. We hope this will be a no-op but in an edge caseRmight have been updated in the intervening seconds - Pull
Rlocally into/var/cache/eos-image-builder/tmp/ostree-co/ostree/repo - Deploy
Rto/var/cache/eos-image-builder/tmp/ostree-co
It feels a bit like there is one too many pull/deploy, particularly in the case where the outermost system is also a deployment of R. But I think all the steps are needed!
| 'ostree', | ||
| f'--repo={repo_path}', | ||
| 'checkout', | ||
| '--force-copy', |
There was a problem hiding this comment.
I checked the documentation for this argument and it says:
Never hardlink (but may reflink if available)
Oh! for btrfs or xfs or some other COW-capable filesystem.
| keys = sorted(itertools.chain.from_iterable( | ||
| glob.iglob(os.path.join(d, '*.asc')) for d in keysdirs | ||
| )) |
There was a problem hiding this comment.
Not a criticism of your code, but I really hate how the only two options for flattening [[T]] to [T] in a list/generator comprehension are this or
keys = sorted(
x
for d in keysdirs
for x in glob.iglob(os.path.join(d, '*.asc'))
)neither of which is particularly pleasing on the eye.
There was a problem hiding this comment.
Totally agree. I find the multiple fors in comprehensions so confusing that I never use them. But then I end up doing something equally ugly like this.
| # Pull the ostree. Ideally the eosminbase ostree would be used to | ||
| # minimize the buildroot, but that's not released and would fail with | ||
| # --use-production-ostree. |
There was a problem hiding this comment.
A shame indeed… Maybe we could change that at some point but I don't think we want to block this change on that. (Another way to look at this would be as an incentive to make the OS as small as possible! But the builder never needs GNOME Shell.)
There was a problem hiding this comment.
I'd hope that in the glorious future you'd just use a privileged container and then you could use the barebones eos image.
|
I'm running this locally and it seems to work just fine. |
Tis a bit much. #4 could be skipped, but it should be fast even if the remote did get updated. |
|
The build succeeded. Let's do it! |
The buildroot construction with
mmdebstrapis fragile and depends on knowing the apt sources for the OS branch. Instead, use the ostree that's going to be used for the image for the buildroot since that already has the proper apt configuration. That means that the host requiresostreerather thanmmdebstrapandrsync. In 2023 I think that's reasonable.https://phabricator.endlessm.com/T35019