On Wed, Mar 8, 2023 at 8:21 AM Alfredo Moralejo Alonso <amoralej at redhat.com> wrote: > Hi, > > On Tue, Mar 7, 2023 at 6:06 PM Colin Walters <walters at verbum.org> 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). > > As part of Cloud SIG, I think that's a good reason to look for a more > appropriate (or maybe a new) SIG for this effort. Other in the ML may > have ideas about other SIGs that may be a better place. > > > > > 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? > > Thanks for this detailed explanation about bootc use cases (I'm eager > to test it). > > IIUC, the expected deliverables that you have on mind for the SIG are > bootc (and maybe others) rpm packages, one or more bootc container > images in some official centos namespace in quay and, at some time, > maybe an alternative anaconda installer or other tools with support > for bootc images? > > Best regards, > > Alfredo > I'm wondering if the Alternative Images SIG[1] is the SIG you need. We were thinking of doing containers, but it was farther down on the list of things to get working. The containers we were thinking of were "desktop" containers. Where the application would be something graphical, or even possibly a whole desktop. But I could see being able to create bootc containers with the same infrastructure, once it get's setup. 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? Troy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20230308/8f58a726/attachment-0002.html>