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. But if we do publish our bootc/container images on 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.
Troy
On Mon, Nov 25, 2024 at 10:01 AM Troy Dawson 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. But if we do publish our bootc/container images on 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 for its containers on quay.io. I'd go with quay.io/centos-altimages for the AltImages SIG.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Mon, Nov 25, 2024 at 7:06 AM Neal Gompa ngompa13@gmail.com wrote:
On Mon, Nov 25, 2024 at 10:01 AM Troy Dawson 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. But if we do publish our bootc/container images on 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 for its containers on quay.io. I'd go with 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.
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
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 theygo?
> > (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
Right now, there are bootc images at https://quay.io/repository/centos-bootc/centos-bootc that come from https://gitlab.com/redhat/centos-stream/containers/bootc
On Mon, Nov 25, 2024 at 7:01 AM Troy Dawson 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. But if we do publish our bootc/container images on 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.
Troy
[1] - https://pagure.io/centos-sig-alt-images/sig/issue/10
devel mailing list -- devel@lists.centos.org To unsubscribe send an email to devel-leave@lists.centos.org
-
Christian Glombek -
Fabian Arrotin -
Jason Brooks -
Neal Gompa -
Troy Dawson