Send devel mailing list submissions to
devel@lists.centos.org
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
devel-request@lists.centos.org
You can reach the person managing the list at
devel-owner@lists.centos.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of devel digest..."
Today's Topics:
1. CentOS bootc images - Where should they go (Troy Dawson)
2. Re: CentOS bootc images - Where should they go (Neal Gompa)
3. Re: CentOS bootc images - Where should they go (Troy Dawson)
4. Re: CentOS bootc images - Where should they go (Fabian Arrotin)
----------------------------------------------------------------------
Message: 1
Date: Mon, 25 Nov 2024 07:00:54 -0800
From: Troy Dawson <tdawson@redhat.com>
Subject: [CentOS-devel] CentOS bootc images - Where should they go
To: "The CentOS developers mailing list." <centos-devel@centos.org>
Message-ID:
<CAKndyURTg52b6JwzgjddYDiW-gE9b6-RB30GL7ejz6NxcgBO6w@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="00000000000077ac470627be00b8"
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
-------------- next part --------------
A message part incompatible with plain text digests has been removed ...
Name: not available
Type: text/html
Size: 2200 bytes
Desc: not available
------------------------------
Message: 2
Date: Mon, 25 Nov 2024 10:05:00 -0500
From: Neal Gompa <ngompa13@gmail.com>
Subject: [CentOS-devel] Re: CentOS bootc images - Where should they go
To: "The CentOS developers mailing list." <devel@lists.centos.org>
Message-ID:
<CAEg-Je8+Ny28L8vQ-R42KDG+g8BW-4c2WgLWpywftuMLZaxD9A@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
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!
------------------------------
Message: 3
Date: Mon, 25 Nov 2024 07:34:56 -0800
From: Troy Dawson <tdawson@redhat.com>
Subject: [CentOS-devel] Re: CentOS bootc images - Where should they go
To: "The CentOS developers mailing list." <devel@lists.centos.org>
Message-ID:
<CAKndyUSW4c=oqiWQ+idsdr1YCifk-0mooHuX2x4ToWoa-4dwmg@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="0000000000002cef7e0627be7a90"
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.
-------------- next part --------------
A message part incompatible with plain text digests has been removed ...
Name: not available
Type: text/html
Size: 2991 bytes
Desc: not available
------------------------------
Message: 4
Date: Mon, 25 Nov 2024 16:40:48 +0100
From: Fabian Arrotin <arrfab@centos.org>
Subject: [CentOS-devel] Re: CentOS bootc images - Where should they go
To: devel@lists.centos.org
Message-ID: <5bef8a8d-07e9-4c24-9d75-ad6f53626683@centos.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="------------mLgsBsEeLLh0nU43OFTA9Gwa"
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]
-------------- next part --------------
A message part incompatible with plain text digests has been removed ...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
------------------------------
Subject: Digest Footer
_______________________________________________
devel mailing list -- devel@lists.centos.org
To unsubscribe send an email to devel-leave@lists.centos.org
------------------------------
End of devel Digest, Vol 237, Issue 3
*************************************