Related to this is https://gitlab.com/redhat/centos-stream/containers/bootc which contains manifests for Tier-0 and Tier-1 (and soon Tier-X) that'll be built using solely CentOS Stream contents.

I'm not sure whether these builds are currently being pushed anywhere. The repo isn't very up-to-date either at the moment.

Tier-X is the suggested common base for downstream derivatives to layer upon, so downstreams don't need to run their own base image composes. Doing that might not be feasible for all SIGs, but at least for some it is (e.g. Cloud for SCOS/OKD).

Christian Glombek (he/him)

Senior Software Engineer

Red Hat GmbH

cglombek@redhat.com

Red Hat GmbH, Registered seat: Werner-von-Siemens-Ring 12, D-85630 Grasbrunn, Germany  
Commercial register: Amtsgericht München/Munich, HRB 153243,
Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross

On Mon, Nov 25, 2024 at 4:41 PM Fabian Arrotin <arrfab@centos.org> wrote:

On 25/11/2024 16:34, Troy Dawson wrote:
> On Mon, Nov 25, 2024 at 7:06 AM Neal Gompa <ngompa13@gmail.com
> <mailto:ngompa13@gmail.com>> wrote:
>
> On Mon, Nov 25, 2024 at 10:01 AM Troy Dawson <tdawson@redhat.com
> <mailto:tdawson@redhat.com>> wrote:
> >
> > The CentOS Alternative Images SIG has recently been asked about
> making CentOS bootc images.[1]
> >
> > Investigation is showing that we should be able to. But that
> leads to the next question. After we build them, where would they go?
> >
> > (A) Initial thoughts are someplace in the CentOS SIG
> infrastructure. But there currently isn't anything setup for
> serving containers. It's also not the first place people would look.
> >
> > I was thinking of having them on quay.io <http://quay.io>.
> > But if we do publish our bootc/container images on quay.io
> <http://quay.io>, where?
> >
> > (B) centos:<some-name> ?
> > That would mean that the SIG's would have access to that account.
> > I also don't know what we would have for <some-name>.
> > We would have to have something different for each SIG.
> >
> > (C) centos-sig:<some-name> ?
> > The SIG's would still have to share authentication in some manner.
> > I still don't know what to do for the names.
> >
> > (D) centos-<sig-name>:<some-name>
> > The SIG's would have their own authentication.
> > The sig's would have control of their own naming convention.
> > centos-altimages:stream10-bootc
> > centos-altimages:stream10-bootc-kde
> > centos-isa:stream9-bootc-baseline
> > centos-isa:stream9-bootc-optimized
> > There are some drawbacks for this. Someone would have to know the
> SIG name to find the image. Possibly other things.
> >
> > I personally am leaning towards (D). But I could be persuaded
> towards the others. And it's possible I haven't even thought of the
> correct solution.
> >
> > Ideas / thoughts / comments welcomed and wanted.
> >
>
> CentOS Hyperscale currently uses quay.io/centoshyperscale <http://
> quay.io/centoshyperscale> for its
> containers on quay.io <http://quay.io>. I'd go with quay.io/centos-
> altimages <http://quay.io/centos-altimages> for the
> AltImages SIG.
>
>
> That's a good point. I didn't even think to ask what the other SIG were
> already doing and/or planning.
>

Before deciding where such artifacts should land, I'd prefer to know if
that's something that should be built on CentOS Infra, or elsewhere ?
Because if that's built on centos infra (like cbs but it doesn't do that
-yet- ), the actual releng process should be aware of this and have auth
token (managed by each SIG, independently from ACO ?) to be able to push
to it.

If that's built outside of CentOS infra, and so that each SIG is
autonomous about how to build (probably on their own infra ?), where to
push and so how to announce it, I guess it doesn't matter

--
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]

_______________________________________________
devel mailing list -- devel@lists.centos.org
To unsubscribe send an email to devel-leave@lists.centos.org