Re: coreos-diskimage-rehydrator
On Fri, Jul 23, 2021, at 10:23 AM, Richard W.M. Jones wrote:
Yeah I saw it but as with many things I didn't necessarily understand
it :-( So in fact it's nothing to do with streams as I was thinking
about it. I guess "stream" means something like "software stream",
as
in which distro and stable version series.
Right. For us this is what a "release" is, and it's how we expect most
people to find machine images to use.
I gave a talk about this. I don't know if it's at all
relevant to
what you're doing, but here it is:
"Disk image pipelines: Efficiently copying, sparsifying, modifying,
streaming multi-terabyte disk images between systems"
http://oirase.annexia.org/tmp/disk-image-pipelines.mp4
Hmm. I think the big difference here is that our "golden" OS images don't
have any user data, so they're never¹ going to be measured in TB. Most scenarios
pulling down a ~1GB image just via `curl` (or our fancier `coreos-installer download` CLI)
is going to be fine.
> However, shipping tons of disconnected container images is chaos
-
> how do you CI test that? (In the same way shipping lots of RPMs
> independently is chaos) So a cool OpenShift 4 specific thing is this
> concept of the "release image" which is a *single container image*
> that contains @sha256 references to all the other containers
> (including the OS updates).
(Sounds like git / docker / Fedora atomic...)
Since we're talking about https://github.com/cgwalters/coreos-diskimage-rehydrator to
start...this would *fully* orient our release process around container images. We never
did anything like this in the Fedora Atomic days which used pungi i.e. the the baseline
"disk images served via Apache directory listing".
This is related but also orthogonal to
https://github.com/coreos/fedora-coreos-tracker/issues/812 which is encapsulating the
in-place OS update (equivalent "set of RPMs" e.g. or for us "ostree
commit") as a container image.
I just have to emphasize it's trying to orient how we deliver the OS (and how we CI
test it, how we version it, how we store those versions, etc.) to be oriented around
container images.
Nothing stops us from shipping a (traditional yum + cloud-init) qcow2 via this, or for
that matter a Anaconda ISO. But the assumption here is admins who want a CoreOS-style
system want a "container native" flow.
The "bootimage" here is (for example) the Fedora AMI that
might be
shipped in Amazon. So it would contain the bootloader, kernel, and a
base distribution?
This "bootimage" term is touched on in
https://github.com/coreos/fedora-coreos-tracker/blob/main/internals/READM...
as well as
https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionable-an...
But basically: the AMI/OpenStack qcow2/etc. are just a "shell" or
"wrapper" for the ostree commit which is 99% of the operating system. And as
that page says, crucially that ostree commit is *bit for bit identical* across platforms.
We don't have anything like "just tweak /etc/resolv.conf on OpenStack only".
An ostree commit is a pair of (kernel + userspace) but *not* the bootloader which is
indeed part of the disk image.
See https://github.com/coreos/bootupd for addressing bootloader updates.
¹ I hope.