Hi Everyone,
Our next board meeting will take place at 20:00 UTC tomorrow:
`date -d "2023-06-14 20: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 Zoom 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/ry93GGRI2
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.
Sorry for the late announcement.
thanks,
--
Thomas 'alphacc' Oulevey
CentOS Board of Directors Secretary
alphacc(a)centosproject.org
Forwarding here the info that was sent to Fedora infra list (
https://pagure.io /fedora-infrastructure/issue/11365 )
In summary, today you'll probably see some services being unreachable,
and impacted services are the ones located in the Fedora DC (it doesn't
impact https://cbs.centos.org and others).
Impacted services:
- https://accounts.centos.org (and https://fasjson.fedoraproject.org
that some infra services are using to retrieve users info and groups)
- ns2.centos.org
Worth knowing that, due to network upgrade, we'll also have to power off
in advance some Virtual Machines that are located on a remote iscsi
block device. And at the same time we'll also convert some VMs/KVM hosts
from centos 7 to el9
Kind Regards,
--
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]
Dear all,
There has been an inquiry to the CentOS Board to clarify how long SIGs
can expect to be able to build against RHEL build targets [1]. This is
necessary to allow SIGs themselves to communicate expected lifecycle of
their content to users.
The outcome of this, in summary, is that SIGs should be able to build
against RHEL until it reaches EOL (end of Maintenance Phase) + 30 days
(no access to ELS content). This policy follows the one used by EPEL.
Note: It is (obviously) still up to every single SIG to decide if and
for how long they want to support a particular RHEL (or CentOS Stream)
release.
This inquiry also included respectively raised some technical questions.
These technical questions are not to be decided by the CentOS Board. In
[2] it has been recommended to discuss these on centos-devel. So let's
do that.
I want to start with two open questions which I do know of. In case
there are other open question concerning this matter please raise them here.
First open question is where to push content produced by SIGs for RHEL8 to.
To better understand the issue, let me summarize the current situation,
for which we first need to define the used format for tags in CBS:
<sig><el>-<project>-<version>-{candidate,testing,release}
where <el> can currently be 7,8,8s,9,9s
Packages tagged for -testing are pushed to:
https://buildlogs.centos.org/centos/<el>/<sig>/<arch>/<project>-<version>/
Packages tagged for -released are push to:
If el = 8 or 8s:
debuginfo rpm packages:
https://debuginfo.centos.org/centos/<el>/<sig>/<arch>/<project>-<version>/
src.rpm packages:
https://vault.centos.org/centos/<el>/<sig>/Source/<project>-<version>/
Everything else:
http://mirror.centos.org/centos/<el>/<sig>/<arch>/<project>-<version>/
If el = 9 or 9s:
http://mirror.stream.centos.org/SIGs/<el>/<sig>/<arch>/<project>-<version>/
For src.rpm <arch> is source.
Note: Although it is not relevant for the discussion, in fact on the
mirrors the suffix "s" of <el> is replaced by "-stream".
This currently is all fine. However it is planned that the
infrastructure currently used for packages built for 8 or 8s will
disappear once CentOS Stream 8 and CentOS Linux 7 are EOL (June 30th,
2024). So in case any SIG decides to produce content for RHEL 8 after
that date packages can not be distributed properly anymore.
Only using the -testing tag and thus https://buildlogs.centos.org is not
really an option as it would probably produce too much load on these.
My proposal: After CentOS Stream 8 went EOL (May 31st, 2024), which is
the same date as the end of the Full support phase of RHEL 8, at least
the -release tag of all RHEL 8 build targets is locked and SIGs have to
opt-in in case they want to build content for RHEL 8 during its
Maintenance Support phase (End: May 31st 2029) for a particular build
target. For these, tagging for -release will then push content to
http://mirror.stream.centos.org/SIGs/8/<sig>/<arch>/<project>-<version>/,
i.e. the same location as used for 9 and 9s.
This gives SIGs one month for all required changes before the currently
infrastructure disappears.
Of course this means additional work for SIGs and Infra. However at some
point the location where to push content to has to be changed before the
currently used infrastructure disappears. Choosing an earlier date would
result in work for SIGs who do not want to continue providing any
packages once RHEL 8 enters Maintenance Support phase anyway.
The second open question concerns the centos-release-* packages provided
by SIGs to allow users to easily consume SIGs' content. For 8s and 9s
the CBS tags extras<el>-extras-common-{candidate,testing,release} are
used to build these packages. This repository is added in CentOS Stream
8 and 9.
For packages build for RHEL 8 and 9 there is currently no common way to
provide any means of easing the process to consume SIGs' content.
My proposal to fix this is by adding
extras<el>-extras-common-{candidate,testing,release} for <el> = 8 and 9,
i.e., using the same system as currently used for 8s and 9s.
To further ease the process I propose to introduce a package named
centos-release-extras which contains the repository config pointing to
the content of the tags extras<el>-extras-common-{testing,release} (only
-release enabled by default) and the CentOS-SIG-Extras GPG key. The
centos-release-extras packages itself would be built in the
extras<el>-extras-common-el<el> build target. Users of RHEL would then
only need to install this single package to allow them to easily install
any other centos-release-* packages. Obviously someone needs to maintain
the centos-release-extras package. I volunteer to maintain this package.
[1]: https://git.centos.org/centos/board/issue/82
[2]: https://pagure.io/centos-infra/issue/1002
Hi All,
As Florian Weimer originally proposed, we have created the CentOS ISA
SIG to focus on potential benefits of newer ISA baselines and
optimizations. You can find our bare-bones SIG docs here:
https://sigs.centos.org/isa/
We'll be adding more information to that site over the coming weeks.
For now, we're getting SIG projects setup and bootstrapped. There is
a #centos-isa libera.chat IRC channel for the SIG and anyone
interested is welcome to join and follow along.
We'd like to thank the CentOS community and Board for their support,
the CentOS Infra team for the rapid response and help, and the
Hyperscaler SIG for providing some great examples to follow on SIG
setup.
josh
======================================================
#centos-meeting: CentOS Cloud SIG meeting (2023-06-08)
======================================================
Meeting started by jcapitao[m] at 14:59:47 UTC. The full logs are
available athttps://www.centos.org/minutes/2023/June/centos-meeting.2023-06-08-14.59.…
.
Meeting summary
---------------
* roll call (jcapitao[m], 15:00:06)
* centos-release-cloud RPM contains now the GPG key of Cloud SIG
(jcapitao[m], 15:04:43)
* all centos-release-openstack CS9 RPMs requires it now (jcapitao[m],
15:05:13)
* LINK:
https://git.centos.org/rpms/centos-release-openstack/pull-requests
(jcapitao[m], 15:07:20)
* OKD/SCOS updates (jcapitao[m], 15:22:29)
* current pre-release:
https://github.com/okd-project/okd-scos/releases/tag/4.14.0-0.okd-scos-2023…
(lorbus, 15:22:44)
* current latest release:
https://github.com/okd-project/okd-scos/releases/tag/4.13.0-0.okd-scos-2023…
(lorbus, 15:23:04)
* work has begun to onboard OKD dependency RPMs to CBS (lorbus,
15:23:43)
* OKD repo files are available in the centos-release-okd-4.13 and
centos-release-okd-4.14 RPMs (from extras-common) (lorbus,
15:25:35)
* OKD cluster on MOC is down for maintenance until June 12 (lorbus,
15:29:34)
Meeting ended at 15:44:40 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* jcapitao[m] (40)
* lorbus (22)
* amoralej (8)
* centguard (7)
* spotz_ (5)
Generated by `MeetBot`_ 0.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
Hello,
I have few questions related to the cloud images provides for c8s and
c9s, i.e.:
- https://cloud.centos.org/centos/8-stream/x86_64/images/
- https://cloud.centos.org/centos/9-stream/x86_64/images/
1) I see the c9s images are regularly updated, while the c8s images not;
is this wanted, or simply a mistake/miss somewhere? If so, will they be
kept up-to-date just like the c9s images?
2) are the Vagrant images there officially supported? Let's say you use
one, and find a bug; then check on a "classic" installation
(baremetal/VM), and the bug isn't there; can users report problems in
those cases?
3) would it be possible to have either unversioned or "-latest" symlinks
for the latest versions of all the files (i.e. images, checksums, etc)?
This way, it will be much easier for users to fetch the latest versions
with no need to change URLs frequently. Of course, the assumption is
that users of this are always willing to use the latest version.
Thanks!
--
Pino Toscano
I've started getting questions about moving from CentOS Stream 8 to CentOS
Stream 9.
I am not the biggest expert on that, so I am bringing the question to the
community.
Have you migrated a Stream 8 machine to Stream 9?
If so, would you mind sharing your steps?
I've already had one person respond as I asked around, and this is the
writeup that they used, with some minor changes (different packages).
https://ahelpme.com/linux/centos-stream-9/how-to-upgrade-to-centos-stream-9…
Troy
https://blog.centos.org/2023/05/centos-connect-at-flock-2023/
The CentOS team is excited to announce that we will be hosting a CentOS
Connect event at Flock to Fedora on August 2, 2023. CentOS Connect is a
series of mini-conferences that showcase the latest developments across
the Enterprise Linux ecosystem. These events are usually colocated with
other open source conferences to help reach a broad audience. Flock is
Fedora's flagship annual conference, bringing together Fedora
contributors and community members to share ideas.
Flock will take place August 2-4, 2023 in Cork, Ireland. CentOS Connect
will be embedded in Flock as a dedicated track on August 2.
Registration, CFP, and venue details will be available on the Flock
website.
This will be Fedora's first return to an in-person Flock since 2019,
and we're very excited to partner with them to make this amazing
conference happen again. The developments in Fedora over the following
year will set the stage for CentOS Stream 10, so this is an ideal time
for us to come together and collaborate. We hope you're able to join us
in Cork to enjoy these two amazing events together.
https://connect.centos.org/https://flocktofedora.org/
--
Shaun McCance
CentOS Community Architect
It was pointed out that we don't have CentOS Stream's image retention
policies written down anywhere. We're in the process of getting those up
into the docs section. But I figured an email would get them out quicker
while we work on that.
CentOS Stream Image Retention Policies:
* Images on CentOS Cloud:
https://cloud.centos.org/centos/8-stream/https://cloud.centos.org/centos/9-stream/
** Policy: All images are kept for a month. After that, we only keep one
set of compose images per month, for up to a year. (I hope that makes
sense)
** Images: container, ec2, qcow, vagrant
Containers on Quay:
https://quay.io/repository/centos/centos?tab=tags
** Policy: Only the latest images are kept.
** Images: container
AMI's on AWS:
** Policy: Images are kept for 180 days
** Images: ec2 AMI's
Questions and/or possible better wording is welcome.
Troy