On Thu, Mar 9, 2023, at 10:46 AM, Duncan, David via CentOS-devel wrote: > > I have a lot to learn here so, my curiosity is piqued. I think a "magic moment" is actually trying out the "manage my OS via container build git-ops" flow. It's not just the mechanics. It's being able to apply every tool and technique one knows about application container images to the problem domain. The "git push" -> automatic container build -> push to registry happening on the server, then on the client you can just `bootc upgrade` and get that change. > I don't see a reason to support another SIG for this image model. You > are talking about supporting a different kernel though and that might > (though I suspect it is not) be a greater burden on image builds. Let's be very clear, while I mentioned kernel-rt there is no separate kernel involved here, and all this technology works with the kernel options enabled today in the C9S kernel. [I don't want to digress but I'm excited about the composefs/overlayfs-verity work but it's not required] > Cloud, to me, is focused around that managed experience that I think > you are describing, be it isolated to a desktop or a raspberry-pi. Sure > there are much deeper layers of abstraction to use, but I think that > those are great environments for experimentation that later ends up > feeding a larger cloud experience. I think that this is a good fit. Hmmm. If cloud extends to (on premise, physical, not actually cloud hosted) desktops and raspberry-pi, then where does cloud stop? > It doesn't seem to me that you think this is going to be in "demo" for > that much longer and you have high confidence that this will be a > better fit ultimately for the community. Recent discussions have also > pointed me in that direction. I hope so, yes! A key point in the creation of bootc is that the "bootc upgrade" part is actually just a fresh new coat of paint on top of underlying infrastructure that has been there a long time (ostree is about 10 years old), and it also crucially builds on top of the github.com/containers/image library which is also battle tested. The "bridge" code between ostree and the containers stack is over 1 year old now; young, and we've hit bugs (e.g. https://github.com/ostreedev/ostree-rs-ext/issues/405 is a great example) but it definitely does work and in fact we are shipping it in OpenShift 4.12 by default for OS updates today. OTOH, `bootc install` is much newer and much less battle tested (but to write it I reused a lot of code we had around coreos land). > I have heard other advanced developers discuss getting to this lower > level in my own world and I would love to see if you can make it work > faster with the support of the team. Selfishly, I'd also like to have > your help on what you might consider misleading about the word "cloud". At a practical level today, "Cloud" to me is usually in this context another term for IaaS virtualization, and guest VMs that are assumed to use cloud-init. Obviously the term is vague and people use it to also speak of general SaaS offerings etc. But I hope you'd agree that it's less common to use it to speak of bare metal deployments - or at least, where it is it's usually as a *provider* of a cloud (e.g. OpenStack/Kube (particularly with KubeVirt) or perhaps at smaller scale the Proxmox etc.) As I mentioned in the kubevirt thread, it is an explicit toplevel goal to have bootc go where podman goes, and work the same way podman works. It's not an accident that it lives in github.com/containers and not some other org. Is podman part of "cloud"? Yes, and no. But in the same way as we (I think most here would agree) think of being able to run application containers as just part of the OS, being able to *boot* containers is also just an operating system feature, not a cloud feature.