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