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
Please unsubscribe me
On Mon, Nov 25, 2024 at 5:41 PM <devel-request(a)lists.centos.org> wrote:
> Send devel mailing list submissions to
> devel(a)lists.centos.org
>
> To subscribe or unsubscribe via email, send a message with subject or
> body 'help' to
> devel-request(a)lists.centos.org
>
> You can reach the person managing the list at
> devel-owner(a)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(a)redhat.com>
> Subject: [CentOS-devel] CentOS bootc images - Where should they go
> To: "The CentOS developers mailing list." <centos-devel(a)centos.org>
> Message-ID:
> <
> CAKndyURTg52b6JwzgjddYDiW-gE9b6-RB30GL7ejz6NxcgBO6w(a)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
>
Hi Everyone,
Our next board meeting will take place at 21:00 UTC next Wednesday
`date -d "2024-11-13 21:00 UTC"`
If you would like to attend please send me an email to
alphacc(a)centosproject.org ( please do not reply to @centos-devel or use
another email address) and you will receive a link to a meeting
room with a passcode, 1 hour before the meeting takes place.
The agenda can be checked at (work in progress) :
https://hackmd.io/@centosboard/SJDtP3cZJe
As a reminder we will enforce few rules :
* Wait to be recognized by the Chair before speaking
* Respect the Chair when told your time to speak is over - this will
allow us to remain on agenda, and complete the meetings in the
allotted time
* In the event that there are Board-confidential topics, these will be
put at the end of the meeting, in Executive Session, and guests will be
asked to leave. We hope to minimize these items, but they do sometimes
happen. The most common scenarios in which this may happen are personnel
issues, or information that Red Hat wishes to share with the Board, but
is not yet public.
* Muting of participants, or, in extreme situations, ejection from the
meeting, is at the sole discretion of the Chair.
* Meetings will be recorded, and published to YouTube (possibly with
edits/redaction, as approved by the Directors). Thus, by joining the
meeting you consent to have your presence at the meeting, and anything
you say during the meeting, made public.
I hope some of you can join.
thanks,
--
Thomas 'alphacc' Oulevey
CentOS Board of Directors Secretary
alphacc(a)centosproject.org
Sending this ticket for awareness : In the last days, I had time to
disable some koji builders (https://cbs.centos.org/koji/hosts) ,
reinstall/migrate these from el8 to el9, and enable these builders back
in the available pool.
It finished today [1] and so all builders, all architectures are now
running el9.4 .
Only the kojihub infra is still running on el8 but that will be migrated
later (kojihub itself doesn't have any impact on build infrastructure).
The main reason why we updated was to ensure we'd be running a newer
kernel for the systemd-nspawn isolation, that was causing troubles when
running on top of el8 (kernel 4.18) , especially when relying on likcapi
calls from within the chroot'ed build env.
For more details and workaround (not needed anymore) that we used to
allow building CentOS Stream 10 pkgs for SIGs, see [2]
At the same time, what triggered also the reinstall was also the need to
re-balance workload across different hardware/chassis [3] : the x86_64
kojid builders are in fact running on some un-warrantied (and older)
machines and I wanted to reconfigure similar machines dedicated
previously for some other things (including CI / on-premises openshift
cluster / etc) to ensure that we'd still have some x86_64 builders
running behind https://cbs.centos.org, should we encounter a whole
chassis hardware failure .
Same for some small services used by koji builders themselves (like
small cache/proxy to retrieve external content, like gitlab.com - now
spread across two distinct hardware with ucarp and floating ip
address[es] for ha purposes)
You'll see that we have now more x86_64 builders, and that some tasks
(like createrepo, rebuildSRPM, etc) are exclusively targeted on these
hosts, freeing some cpu cycles from aarch64/ppc64le/s390x builders, that
will be only used for specific rpmbuild tasks.
Also worth knowing that I was able (due to decommissioned cores/memory
that was used for centos stream 8/centos linux 7) to extend/tune number
of cores/available memory on reinstalled aarch64 and ppc64le koji
builders, hopefully helping to build faster your SIGs packages for these
architectures.
Nothing is required from you, SIGs builders, as the whole migration
happened transparently , without any downtime, so just enjoy more
compute capacity / redundancy for https://cbs.centos.org (and let's hope
that we'll not suffer from hardware failure in the future)
[1] https://pagure.io/centos-infra/issue/1505
[2] https://pagure.io/centos-infra/issue/1474
[3] https://pagure.io/centos-infra/issue/1528
--
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]
** Please read this entire email before responding with nominations.
** We have a process, and the process is important.
Recently, Brian Exelbierd notified the CentOS board that he will be
moving on from his role as Red Hat Liaison. The Red Hat Liaison role is
special: it is the only board seat appointed by and speaking for Red
Hat. All other board members are at-large and speak for themselves.
Brian's role will be backfilled, but until it is, Josh Boyer will step
in as the interim Red Hat Liaison. This means that Josh is stepping
down from his position as an at-large board member.
See Brian's and Josh's emails for more info:
https://lists.centos.org/hyperkitty/list/devel@lists.centos.org/thread/QAG4…https://lists.centos.org/hyperkitty/list/devel@lists.centos.org/thread/BCWM…
We are asking you, the CentOS community, for nominations for who should
fill Josh's seat. Note that the vote on who will fill this seat is held
by the board itself, but nominations are open to the entire community.
If you would like to nominate someone (or self-nominate), please use
this Google form:
https://forms.gle/jqYF7v5AUVy6L1Fz6
Please DO NOT send nominations to this list. As this is not a public
vote, we don't want to give the impression of a popularity contest with
public nominations. We also want to avoid any shaming if someone is
nominated and is not seated, or chooses not to accept.
I will ensure that each nominee is willing and able to serve, and the
board will consider them and select the next director from the list.
If you wish to nominate someone, you should consider the list of
director requirements and recommendations listed at:
https://www.centos.org/about/governance/director-requirements/
Nominations will be open until September 23.
Thank you for your thoughtful consideration and participation in this
process.
--
Shaun, for the CentOS Board of Directors