<div dir="ltr"><div dir="ltr">On Wed, Mar 8, 2023 at 8:21 AM Alfredo Moralejo Alonso <<a href="mailto:amoralej@redhat.com">amoralej@redhat.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On Tue, Mar 7, 2023 at 6:06 PM Colin Walters <<a href="mailto:walters@verbum.org" target="_blank">walters@verbum.org</a>> wrote:<br>
><br>
> 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.<br>
><br>
> 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.:<br>
><br>
> - 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)<br>
> - Getting away from injecting so much persistent state by default (both via Ignition and outside of it)<br>
><br>
> 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.<br>
><br>
> As part of this (potential) re-architecture of how we think of systems management, I created the <a href="https://github.com/containers/bootc" rel="noreferrer" target="_blank">https://github.com/containers/bootc</a> 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 <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 *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.<br>
><br>
> 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.<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 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.<br>
> - Or, create a new SIG<br>
><br>
> 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).<br>
<br>
As part of Cloud SIG, I think that's a good reason to look for a more<br>
appropriate (or maybe a new) SIG for this effort. Other in the ML may<br>
have ideas about other SIGs that may be a better place.<br>
<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 <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> ) 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).<br>
><br>
> Another way to say it is that I'd love to ship <a href="http://quay.io/centos/centos-boot:stream9" rel="noreferrer" target="_blank">quay.io/centos/centos-boot:stream9</a> (notice the -boot).  Or failing that, it'd be <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 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: <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> - 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<br>
>  reprovisioning).<br>
><br>
> At the same time, bootc already introduces some quite new things that need design iteration; for example: <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 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 <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>
Thanks for this detailed explanation about bootc use cases (I'm eager<br>
to test it).<br>
<br>
IIUC, the expected deliverables that you have on mind for the SIG are<br>
bootc (and maybe others) rpm packages, one or more bootc container<br>
images in some official centos namespace in quay and, at some time,<br>
maybe an alternative anaconda installer or other tools with support<br>
for bootc images?<br>
<br>
Best regards,<br>
<br>
Alfredo<br></blockquote><div><br></div><div>I'm wondering if the Alternative Images SIG[1] is the SIG you need.</div><div>We were thinking of doing containers, but it was farther down on the list of things to get working.</div><div>The containers we were thinking of were "desktop" containers.  Where the application would be something graphical, or even possibly a whole desktop.</div><div>But I could see being able to create bootc containers with the same infrastructure, once it get's setup.</div><div><br></div><div>One thing our SIG does not do is create/build packages.  I'm not seeing you say you need new/rebuilt packages.  Do you need new/altered packages?  Or does everything get done via the setup scripts and configs?</div><div><br></div><div>Troy</div><div><br></div><div><br></div></div></div>