manifests: Inherit from Project Sagano

[cgwalters]

Depends #2609

---

manifests: Inherit from Project sagano

[This is just a demonstration/testing change; the git repository
for Sagano is definitely going to change location at least]

Fedora CoreOS predates the time of bootable containers. As such,
it's actually pretty large (relatively speaking). Project Sagano
is a fresh take on more minimal base images.

At the same time, we want to de-duplicate efforts. With this,
CoreOS cherry picks a few manifests from the Sagano "tier-0" and
"tier-1".

There's definitely more we can share between the two, but
this is a notable starting point.

---

[cgwalters]

The technology and social goals here are intertwined: once we merge this, we'll need to think: Should the relevant work be done in Sagano or in FCOS? The definite goal of this PR once it lands is that some of the maintenance work of FCOS actually becomes Sagano work, to be clear.

[dustymabe]

This is titled as demonstration only/WIP, but I think you do want feedback on the idea/direction.

Overall I think the direction is where we want to go in the future (i.e. some "core" thing in Fedora that all other OSTree/ContainerNative distros are based on) so 👍 for that. I do think it would be worth us discussing this more in a forum like the weekly community meeting to at least socialize the direction and to see what other people think.

Were you intending for this to merge soon? For right now I don't think I'd be super comfortable with making a change like this just because of the infancy of the project (i.e. the code name didn't even exist until a few weeks ago and it still lives under cgwalters-playground), but I think maybe once it gets more well established we could consider making a change like this?

[cgwalters]

Overall I think the direction is where we want to go in the future (i.e. some "core" thing in Fedora that all other OSTree/ContainerNative distros are based on) so 👍 for that.

Exactly, thanks!

I do think it would be worth us discussing this more in a forum like the weekly community meeting to at least socialize the direction and to see what other people think.

OK, though this is a developer-only focused change right now to be clear.

Were you intending for this to merge soon?

Definitely not, as the commit message says:

[This is just a demonstration/testing change; the git repository
for Sagano is definitely going to change location at least]

But it's intended to be a conversational starting point as the project progresses. Thanks for the feedback!

[dustymabe]

OK, though this is a developer-only focused change right now to be clear.

Right. It's definitely not end user facing (hopefully), but it does have implications on our overall structure in the future, which I think raises to the level of being meeting worthy.

[jlebon]

This looks sane to me too overall. I'm a bit confused though about https://gitlab.com/CentOS/cloud/sagano including both Fedora and CentOS manifests. ISTM like it'd be clearer to structure the repo as the common denominator and leave repo definitions and distro-specific stuff in one layer above? Ahh OK, I see https://gitlab.com/CentOS/cloud/sagano#plan, though I mean something slightly different. E.g.:

• gitlab.com/<not sure>/sagano
  • inherited by https://github.com/fedora-base
    • inherited by https://github.com/coreos/fedora-coreos-config
    • inherited by https://pagure.io/workstation-ostree-config
    • ...
  • inherited by https://gitlab.com/CentOS/centos-base
    • inherited by https://gitlab.com/redhat/centos-stream/...
    • ...

?

That makes it easier for communities around each of Fedora and CentOS to work on their respective bases without incurring unnecessary churn on the other.

[cgwalters]

To me an explicit goal is to fix the problem with Fedora CoreOS ➡️ ??? ➡️ RHEL CoreOS today.
And more generally, the drift between the 3 things without constant application of rigor...the fact that spec files need to be duplicated between fedora and c9s has caused me pain.

And specifically, a goal of Sagano is to be "ready to ship" even in CentOS Stream 9.

Another related goal is sharing tooling with things like automotive that only have CentOS versions at the moment. Also not unrelated to this, a goal is to build on the momentum from RHT investment in gitlab.com at an OS level and the CI flows there. And to help build the story with integration into dist-git gating.

With these things combined, splitting things up between Fedora and CentOS adds more friction to my mind. Particularly to the scale of all the git repositories you're proposing!

But obviously for now, fedora-coreos-config continues to be in github. That still works fine.

And more generally remember, a bigger goal here is that we do container native derivation which works just great today with Dockerfile etc. (and we have coreos/rpm-ostree#4427 to do). So the git repository structure is irrelevant to those; this is more about sharing code for "base image" builds (which does get into the more tricky topic of how we "productize" building custom base images, which we know we need).

[cgwalters]

A simple thing to game out: What happens when in e.g. fedora rawhide something changes in say the grub/systemd/whatever packaging and we need a change that's rawhide only in the manifest? How does that work? Do we branch in that git repository?

My first response here is that we already have some support for conditionals and rather than git branches we should make it work like spec files.

Will this cause problems? Maybe. But, my feeling is that that cost is going to be dramatically outweighed by the benefits of not allowing things to drift by default and keeping things centralized. EDIT: Right now every PR to the sagano Git is gating on Fedora 38 and C9S, and I think that's a really nice improvement.

[cgwalters]

OK, the sagano git repository is now in a more stable place; lifting draft on this.

[jlebon]

SGTM. Though maybe let's wait until we've cleared f39 GA first?

Also, let's do #2609 first? (Did you see the comments there BTW?)