On Wed, Dec 1, 2021, at 11:33 AM, Neal Gompa wrote: > A couple of things from my perspective: > > * I would like to see how this would enable CoreOS releases to go > through Bodhi To me, a notable chunk of the value of how we're doing FCOS is that our build, test and release processes are tightly intertwined and maintained by the same team. It's really part of having an "image based" delivery flow - we're responsible for that "one thing", instead of a distributed amorphous notion of responsiblity that happens with packages. We have deeply invested in a fully containerized build and test flow. Our build and test code is all in a single big coreos-assembler container. We have a core principle that the pipeline is basically just scripting what exists in coreos-assembler (it doesn't have significant nontrivial logic itself), so it's easy to replicate locally. That's...just not true of most other things in Fedora, and the value of wedging Bodhi (particularly the karma aspect) into the mix isn't clear to me. I would say also that I personally am *very* strongly of the opinion that as a general rule, bespoke imperative web apps/APIs that we require humans to touch are generally a bad idea. Instead, the build and delivery pipeline should be as "git-ops" as possible. We live in this world - see e.g. https://github.com/coreos/fedora-coreos-config/blob/testing-devel/manifest-lock.x86_64.json which defines the content that goes into FCOS. It's JSON stored in git, and bumping it runs through CI. (I would like to consider changing things to be auto-pull-request based, just like Dependabot e.g. so that things are even more obvious; we didn't do that initially out of concerns for PR noise, but lately I'm leaning towards it) There's no database or web API involved, it's just JSON stored in git. This is also similar to e.g. https://github.com/NixOS/nixpkgs/pull/136462 Why should it be any harder than that? But in the end of course, to really answer your question, this change could perhaps indeed make it easier to push ostree-containers through Bodhi. And to be fully clear, a lot of what I wrote above applies to FCOS, but not necessarily to the other editions that use (rpm-)ostree. > That > also means using registry.fedoraproject.org as the primary registry > that replicates to quay.io. Sure, I have no strong opinions there. That's already touched on in https://pagure.io/releng/issue/10399 > * How does this affect Kinoite, Silverblue, and CoreOS releases? Are > they changing immediately to this mechanism? I can't say for sure around time frames and specific editions. But *ideally* for f36: - Client-side capability ships (done! You can try this today! https://coreos.github.io/rpm-ostree/container/ ) - Shipping e.g. quay.io/fedora/coreos:testing-devel with GPG signatures inside (we're keeping ostree GPG signatures even inside a container flow because we care about the OS! xref https://github.com/ostreedev/ostree-rs-ext/pull/76 ) - We get sufficient experience from now till f36 to mark this capability stable in rpm-ostree After that, well it gets fuzzy. I have a lot of work to do on the client end, and I personally plan to drive this from the FCOS side. Where things get quite interesting of course is that suddenly container-style derivation becomes not just a possibility but an obvious thing to do. IOW, it makes it more clearly possible that the Fedora Silverblue build is the equivalent of: ``` FROM quay.io/fedora/coreos:stable RUN yum -y install gnome-shell ... ``` (That said, I would like to keep all the build-side intelligence we have on rpm-ostree that is part of having a declarative input instead of Dockerfile, i.e. we'd still use treefiles etc. This is also related to https://github.com/coreos/rpm-ostree/issues/2326 ) And if we do *that*, then other editions suddenly also get to use all the investment we've made in the FCOS CI too, and it changes how we think about all of this. (Not to mention being able to use Ignition too for desktops, which is its own quite interesting aspect) _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
