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 https://www.redhat.com/ https://www.google.com/maps/place/Engeldamm+64b,+10179+Berlin/@52.5058176,13.4191433,17z/data=!3m1!4b1!4m5!3m4!1s0x47a84e30d99f7f43:0xe6059fb480bfd85c!8m2!3d52.5058176!4d13.421332
cglombek@redhat.com akollmer@redhat.com https://red.ht/sig
Red Hat GmbH https://www.redhat.com/de/global/dach, 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 https://www.redhat.com/de/global/dach https://www.redhat.com/de/global/dach
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