Possible to add vauxite to ostree.fedoraproject.org?

[srd424]

Is your feature request related to a problem? Please describe.

I'm trying to reduce update size for Vauxite. I had originally only discovered the u-blue variant, but eventually discovered that it existed on quay.io/fedora-ostree-desktops, which has slightly lighter updates (as it's fully layered I assume.) They're still quite hefty (100s of MB) for something that happens every couple of days, though.

Describe the solution you'd like

Is it possible for the CI/CD to push vauxite to ostree.fedoraproject.org as well as building the OCI image? At the moment I only see:

fedora:fedora/39/x86_64/kinoite
fedora:fedora/39/x86_64/onyx
fedora:fedora/39/x86_64/sericea
fedora:fedora/39/x86_64/silverblue

Describe alternatives you've considered

I'm aware that the long-term intent is probably to move fully to OCI image based deployment, and the zstd:chunked stuff will presumably reduce update size a lot, but I'm assuming that's dependent on bootc-dev/bootc#215 etc - which I'm guessing is a while away from landing?

Onyx seems to have been added to ostree for Fedora 39 so it seems there isn't a moratorium on adding new spins to ostree yet?

[juhp]

Reading, I think you are asking for Vauxite to be made into an official Fedora ostree image.
(I guess there are plans to rebrand most of the ostree desktops to make them more recognizable).
There may be a more appropriate place to make this request - since this issue tracker is really specific to Silverblue.
Fedora Discussions is probably a better place.

There was some earlier discussion I see, but it needs someone to step up to propose, own and maintain the image.

[travier]

Folks interested in adding new Fedora Atomic variants can follow this rough guide I wrote earlier: https://tim.siosm.fr/blog/2023/06/21/rpm-ostree-variants-fedora/

Most of it is already done. Now we need a maintainer.

Closing as there is nothing to be done on the Silverblue side of things.

[srd424]

Ah, thanks for that blog post link - it was the missing piece of the puzzle trying to understand how everything fitted together! I've been in the Debian/Ubuntu space for ~25 years so this is all a bit new :)

[travier]

Note that we're looking at moving to the container format by default as well, so the ostree remote will go away at some point: https://gitlab.com/fedora/ostree/sig/-/issues/2

[srd424]

Yup, I assume once bootc-dev/bootc#215 lands it can use zstd:chunked and the update size should be roughly comparable with the older ostree based approach.