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/manifes...
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)