On Wed, Mar 8, 2023 at 8:21 AM Alfredo Moralejo Alonso amoralej@redhat.com wrote:
Hi,
On Tue, Mar 7, 2023 at 6:06 PM Colin Walters walters@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/68afb072a5a1396c7...
- 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