On Thu, 2020-12-03 at 14:14 -0500, Josh Boyer wrote: > > > > Beyond the pungi-vs-bodhi thing of course, to me it is also very fundamental that our OS build and test process runs natively via podman and Kubernetes (unprivileged). We're telling people to use containers; building the operating system shouldn't require you to `yum install` (or even `rpm-ostree` install stuff directly on a host system. Our current build pipeline is Jenkins-running-in-OpenShift; we're actively working on removing Jenkins from the equation in some circumstances and making the whole thing even more Kubernetes-native. This is not at all true of the Koji/pungi stack. > > Is that difference really split along tooling lines? I'm not sure it > is. You could use pungi to build updated installation media every > time there's a push of updates. We just... don't. Right. It's a choice, not a capability thing. At this point I think there are two reasons for the choice: 1) It *does* take a long time to produce a full compose, and doing that for every update push for every stable release might overwhelm capacity, I think 2) We don't have the capacity to test full composes very frequently to the level we test "stable releases" 2 is really the awkward one. It's not really a showstopper, but it comes with awkward questions. We could respin every month and go through a full validation process, but that would be a huge lift and eat up basically the whole of QA's time (and probably a lot of releng's, and various other people) and we'd probably still miss stuff. We could produce respins on some sort of schedule and run them through automated testing and maybe some light manual validation and put them out on some kind of "use at your own risk" basis, but there the devil is in the details, particularly of communication. How exactly do you sell the message "these images are PROBABLY actually a bit better than the release ones, and they're almost certainly more secure, but we can't really entirely stand behind them and if you have some problem with them we're going to tell you to use the official release image instead"? It's a tricky bit of communication to do successfully. Even still, we might want to try it. I dunno. But at that point we've gone a bit off the original topic, and there I think Colin hit the nail on the head with "for FCOS we made a massive simplification". Which is a nice thing to be able to do ;) For the thing called "Fedora", we can't really make all those simplifications, because of existing expectations and commitments. So this goes back to my big point: when we make "Fedora CoreOS" a key part of the thing called "Fedora", we have impedance mismatches, and here's another. The thing called "Fedora CoreOS" has made these simplifications in deployment: it's massively restricted what "deployment" means, in terms of what gets deployed where and how. That gives it quite a big payoff in various ways in terms of how development and testing and release can be done. But we really don't have those options for the whole of the thing called "Fedora", not on any sensible timescale at least. Unless Josh wants to start getting really radical about RHEL 9...:D -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
