On Thu, Dec 3, 2020 at 1:59 PM Colin Walters <walters@xxxxxxxxxx> wrote: > > On Wed, Dec 2, 2020, at 12:19 PM, Adam Williamson wrote: > > > > > > What does the question "is Fedora CoreOS 34 ready to go" even mean, in > > the context of how CoreOS is built and released? What set of bits will > > we be deciding to ship or not ship, and how will that have been decided > > and communicated? Where will we look to find the test results and > > criteria on which we would base that decision? > > There are a whole lot of aspects to this, but one angle to look at this from is that I personally have always thought the way Fedora uses pungi up until releases and everything's about a "compose" and then it switches to a Bodhi wild west where updates are unversioned things that can release at any time...well, it doesn't make much sense. > > The concept that you have boot media that can reach 6 months old is a very bad anti-pattern because there are often periods of time where the software there has security vulnerabilities. *Particularly* for a desktop system starting up a 6 month old web browser is just actively dangerous. > > Now I understand there are reasons traditional Fedora does this - among them that Anaconda is a huge thing on its own. But for FCOS we made a massive simplification - the "Live" FCOS *is the same thing as the OS*. Our `coreos-installer` is just a glorified `dd` wrapper (mostly) and all system provisioning logic happens in Ignition, which we're constantly testing all of the time. > (Personally I'm really proud that for example our Live ISO ships with SELinux enforcing) > > FCOS currently respins both an ostree commit and boot media every release, and because we use coreos-assembler all the time, those are all strongly versioned together and consistent. > > 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. This seems more split on the OS consumption model to me, rather than the tools to make it. The end user shouldn't care at all about what tools make it. They just want to install their OS and keep it updated and have those updates NOT BREAK their systems or apps. ostree based OS updates have some inherent benefits that a per-package update model lacks and I find it intriguing because you could test a whole OS update stack to at least ensure it's consistent within itself. Whether that happens or not is up to the creators of the OS. You can do the same with bodhi but we... don't. Neither set of tools can really claim to validate the updates won't break third party apps though. (There is the whole pets vs. cattle dynamic too, but I'm not sure that matters much either. The basic requirements should be the same between both: I install or update my pet or cattle and my stuff keeps working unless I want to migrate to something newer). josh _______________________________________________ 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
