Hey Colin, I'm looking thru my email for stuff that might have gotten dropped. It looks like there was never a resolution to this. Is there anything I can do to move things along? -- Shaun On Tue, 2023-03-07 at 12:00 -0500, Colin Walters wrote: > Hello, I'm a developer on Fedora/RHEL and OpenShift. Lately we've > been landing a lot of "bootable container" changes in OpenShift core, > and there's a lot more to come. > > However, as we've been doing about this...I've been saying to people > that I wish I had a time machine to go back and do bootable > containers from the start. There's a lot of things we're doing today > that I think we should stop doing, e.g.: > > - Switching to kernel-rt by fiddling with each node; we should be > simply pulling a pre-built bootable container image with that kernel > (more on this below) > - Getting away from injecting so much persistent state by default > (both via Ignition and outside of it) > > And crucially, I think we should be developing tools and techniques > that apply *outside* of Kubernetes/OpenShift and also work well with > it. To be direct, I'd like to eventually productize some of what's > happening here in RHEL, not in OpenShift. > > As part of this (potential) re-architecture of how we think of > systems management, I created the > https://github.com/containers/bootc project. To be direct: If > successful, I think bootc will be the successor to (rpm-)ostree. > It's also intended to much more closely align with the > github.com/containers organization. > > A simple way to think of this is: One can (build and) run > *application* containers with podman; and these containers can also > be run in e.g. Kubernetes/OpenShift. One can build *bootable* > containers using any tooling (including podman build), but *running* > them is via bootc on the end machine. bootc understands kernels etc. > > But there's a lot to figure out here - and I want to have a space to > figure out this stuff and experiment with it outside of a direct-to- > product path. I think a CentOS SIG makes sense for this. > > So what I'd like to do is either: > > - Add a new effort to the Cloud SIG, which currently (IMO a bit > confusingly) hosts OpenStack/RDO and OpenShift/OKD things which would > be a 3rd thing. The bootc work would then be the "base OS" split for > OKD/SCOS. But of course, nothing stops one from building bootable > host images that are instead designed to be RDO/OpenStack hosts. > - Or, create a new SIG > > Personally, I lean towards the latter because honestly I find the > naming "Cloud" to be misleading - bootc is also intended to be useful > for standalone, non-cloud-infrastructure settings (such as desktops > and IoT). > > Specifically, I'd like to transfer the existing code that lives in > https://github.com/cgwalters/bootc-demo-base-images (specifically > https://github.com/cgwalters/bootc-demo-base-images/blob/main/c9s.yaml > ) into something CentOS-affiliated and explicitly maintained by a > team. (Though I'm not super excited to move it to pagure like at > least some other SIG content, but let's not get distracted by git > hosting too much here). > > Another way to say it is that I'd love to ship quay.io/centos/centos- > boot:stream9 (notice the -boot). Or failing that, it'd be > quay.io/centos-boot/centos-boot:stream9 or so. There's a *lot* to > discuss in terms of what actually goes in these base images, and also > ensuring it's equally ergonomic for users to build their own base > images. So really it's very likely there wouldn't be just *one* base > image. In fact, I recently introduced a -rt variant with the RT > kernel: > https://github.com/cgwalters/bootc-demo-base-images/commit/68afb072a5a1396c7424ed536a896293fff8287d > - and this was specifically motivated by issues we hit in OCP. But > again, I want to have a space where we try to do more of a "clean(er) > slate" approach for a while, with notes "not for production use" - > for a while. Everything done here though *is* made with that as an > explicit goal though (e.g. it's a toplevel design goal too that > existing ostree-based systems can be seamlessly switched to be > container-based without > reprovisioning). > > At the same time, bootc already introduces some quite new things that > need design iteration; for example: > https://github.com/containers/bootc#using-bootc-install - we ship > tooling such that a container can install itself (without going > through a raw disk image as is used by both OCP and Edge deployments > today). And at the same time, I'd like to aim to get the Anaconda > changes to install these bootable containers in > https://github.com/rhinstaller/anaconda/pull/4561 > > OK this is already too long, so I'm just going to click send =) > Thoughts? > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel >