On Fri, Jul 23, 2021 at 10:04:51AM -0400, Colin Walters wrote:
> On Fri, Jul 23, 2021, at 3:24 AM, Richard W.M. Jones wrote:
> >
> > Hi Colin,
> >
> > Intrigued by what this is doing:
> > https://github.com/cgwalters/coreos-diskimage-rehydrator/tree/main/src
> >
> > A few questions:
> >
> > Don't you have the problem that OSes (eg. OVAs) from VMware won't
> > boot on KubeVirt?
>
> This is unrelated to KubeVirt...or, well it could be tangentially
> related but it really operates on a different layer.
>
> > Not really sure what "streams" refer to in this context.
>
> Did you see the main `README.md` content in
> https://github.com/cgwalters/coreos-diskimage-rehydrator ? That
> document assumes a passing familiarity with Fedora CoreOS but
> "stream metadata" specifically links to
> https://docs.fedoraproject.org/en-US/fedora-coreos/stream-metadata/
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.
> > But if
> > that's referring to streaming as in piping disk images across the
> > network, we've got a bunch of tooling here around this.
>
> I am definitely interested in your opinion on this, and perhaps
> there are indeed some techniques you know of that would apply to
> this problem domain.
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
> However, let's be sure we're on the same page! I and my team live
> in a duality or quantum superposition between Fedora/RHEL and
> Kubernetes/OpenShift. One needs an operating system to run
> OpenShift. But: a huge part of the vision of OpenShift 4 is that
> the operating system is managed by the cluster.
>
> And further OpenShift 4 is not e.g. RPMs installed by something like
> Ansible. Instead, we build and ship the platform the same way our
> customers write applications - as containers. These containers all
> run as Kubernetes pods. Admins can use e.g. `kubectl log` on the
> machine-config-operator to look at the OS upgrade process on a node.
> The thing starting the OS update is a (privileged) container. We
> ship updates to the OS as a container image
> (https://github.com/openshift/machine-config-operator/blob/master/docs/OSUpgrades.md
> ).
>
> 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...)
> And that's what we ship and CI test. If you visit e.g.
> https://amd64.ocp.releases.ci.openshift.org/ and click on e.g.
> https://amd64.ocp.releases.ci.openshift.org/releasestream/4.9.0-0.nightly/release/4.9.0-0.nightly-2021-07-21-081948
> you can see all the CI across many platforms that ran on that release image.
>
> And crucially, that's how we ship it to customers. If for example you want
> to perform a disconnected installation, all you need to do is mirror those
> containers:
> https://docs.openshift.com/container-platform/4.7/installing/installing-mirroring-installation-images.html
> And you get *exactly the same thing* that ran in CI. That's a big deal.
Understood.
> OK now we're finally reaching the point: When I said everything was
> part of the release image, that was kind of a lie, because it's
> everything *except* the RHCOS "bootimages" e.g. AMI/OpenStack
> qcow2/etc.
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?
> And that's the goal of the rehydrator - if e.g. you want to perform
> a disconnected OpenStack/vSphere/etc. install, all you need to do is
> follow those instructions to mirror the set of container images, and
> then on premise you can *run* the rehydrator container and out pops
> a vSphere/OpenStack/etc. image that you can upload to bootstrap the
> process.
OK, I believe I have a better understanding now, thanks!
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-c
