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/README-internals.md#ignitionplatformid as well as https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionable-anti-hysteresis/ 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. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
