Hi Colin, Hi Shaun! This thread had dropped off my radar too until last week. I think it'd be very interesting to build bootc for CentOS Stream, and looking ahead a bit, to experiment with building a bootc-based OKD/SCOS. I went ahead and added Colin to the Cloud SIG group, and I also requested creation of a dist-git repo for bootc: https://git.centos.org/rpms/bootc (alternatively, we could also create a repo for it in https://gitlab.com/CentOS/cloud/rpms) In case it helps anyone, here are some working notes I took for building other RPMs for the Cloud SIG on CBS: https://hackmd.io/Cfzd-r-5QKaFLIP-iCog0A?view Happy to support this effort, please let me know if I can help in any way :) Christian On Wed, Jun 28, 2023 at 4:04 PM Shaun McCance <shaunm at redhat.com> wrote: > 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 > > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20230629/3402f46b/attachment-0002.html>