Welcome to Cloud SiG Colin and bootc!:) *Amy Marrich* She/Her/Hers Principal Technical Marketing Manager - Cloud Platforms Red Hat, Inc <https://www.redhat.com/> amy at redhat.com Mobile: 954-818-0514 Slack: amarrich IRC: spotz <https://www.redhat.com/> On Thu, Jun 29, 2023 at 9:15 AM Christian Glombek <cglombek at redhat.com> wrote: > 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 >> > _______________________________________________ > 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/0f8650b1/attachment-0002.html>