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