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/OSU...
).
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...
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-m...
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-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW