devel September 2021

devel@lists.centos.org

20 participants
16 discussions

Proposal: CentOS Public Board Meetings
by Rich Bowen 07 Jan '23

07 Jan '23

In January of 2021, the CentOS Board of Directors opened our monthly meetings to all SIG chairs, in a first step towards more transparent governance. We wanted to see how the larger audience changed the meeting dynamics, if at all, as well as welcoming a broader pool of voices. We are now ready for the second part of this process. Starting in the August meeting, we will be inviting the entire CentOS community to attend these meetings. Due to the nature of the Internet, we won’t be simply publishing the meeting URL, as this often leads to disruptive behavior in meetings, as I am sure many of you have experienced. Rather, in the week before the meeting, we’ll send, to this list, a way to request an invitation to the meeting. In this way, we hope to limit the incidence of such disruptions, while also making the meeting available to anyone who wishes to attend. We will be working on the rules of engagement for these meetings, but they will be, at minimum: * 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/redactions, 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. Because there will seldom be time for Q&A during the meeting itself, we plan to add a post-meeting IRC office hours session for followup questions. This will probably be scheduled for a week after the board meeting, to allow time to publish meeting minutes We welcome your comments about the above proposal, and thank you all for your patience as we implement these changes to our governance process.

8 27

CPE to staff EPEL work
by Rich Bowen 17 Dec '21

17 Dec '21

We are pleased to announce that Red Hat is establishing a small team directly responsible for participating in EPEL activities. Their job isn't to displace the EPEL community, but rather to support it full-time. We expect many beneficial effects, among those better EPEL readiness for a RHEL major release. The EPEL team will be part of the wider Community Platform Engineering group, or CPE for short. As a reminder, CPE is the Red Hat team combining IT and release engineering from Fedora and CentOS. Right now we are staffing up the team and expect to see us begin this work from October 2021. Keep an eye on the EPEL mailing list[1] and the associated tracker as we begin this exciting journey with the EPEL community. [1] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraprojec… [2] https://pagure.io/epel/issues

9 11

CentOS Stream 9 content available for cbs.centos.org : start your builds !
by Fabian Arrotin 30 Nov '21

30 Nov '21

Hi, Long awaited feature request is now implemented on https://cbs.centos.org : you can now start requesting 9s tags to build against/for CentOS Stream 9 ! I already created some tags/targets for SIGs that already requested it some time ago through our dedicated infra tracker (reminder: https://pagure.io/centos-infra/issues) Worth knowing that the following repositories are enabled by default for all newly created 9s tags: - BaseOS - AppStream - CRB What's possible to add ? I know that for 8/8s some SIGs (like Cloud SIG for openstack) rely on other repositories, like HighAvailability , or others. Feel free to ask such repositories to be added to your build tags. It's also possible to build against CentOS Stream 9 buildroots if the pushed repositories don't include all -devel / runtime packages that you need at buildtime. For that, consider also asking for it if/when needed. Important ! Due to the way Stream 9 will be delivered (more news on that later, probably through Brian and/or Carl), I have locked all -release tags for 9s. What does that mean ? That you can build pkgs, and also tag to -testing (that will go out as usual to buildlogs.centos.org) but not to -release (even if tag is created already). Once we'll have figured out how to properly sign+push SIG content out, we'll announce the plan and also unlock the -release SIG tags Stay tuned for more information about that soon. Kind Regards, -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab

6 11

Announcing https://sigs.centos.org
by Fabian Arrotin 05 Oct '21

05 Oct '21

As pre-announced on the centos-devel list in another thread, and also per Automotive SIG request (https://pagure.io/centos-infra/issue/458) , we'd like to announce new https://sigs.centos.org virtual host, rendering SIG documentation (if they want to) The system is based on markdown documents, rendered through mkdocs (https://mkdocs.org) How can you request your SIG namespace on it ? # prepare a git repository with your .md files and a mkdocs.yml file (see https://www.mkdocs.org/getting-started/) # create a centos-infra ticket on https://pagure.io/centos-infra/issues with : - sig name and description - git origin for your project (where your .md files are stored) : it can be wherever you want, so github, gitlab, pagure.io or even git.centos.org if you ask for a project to be created there for your SIG # once created (by ansible), your content will be automatically rendered and visible under https://sigs.centos.org/<sig_name> (example : https://sigs.centos.org/hyperscale/ , already "live") Once you'll have just accepted PR or pushed commits to your git repository, it will be picked up, rendered and push to https://sigs.centos.org vhost. Suggestion : if your SIG has such documentation online, it would be good to just have a pointer in wiki to the new place, (or even move instructions - if you have some - to the dedicated SIG doc site) -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab

4 6

[REPORT] Automotive SIG
by Jeffrey Osier-Mixon 01 Oct '21

01 Oct '21

October 2021 Quarterly report submitted by: Jefro Osier-Mixon, Red Hat - acting chair _____________________________________ Membership update (members added, removed. Chair changes.) This SIG is new, and as such does not have a formal membership process yet. The mailing list currently has xx subscribers representing at least yy companies. I have been asked to act as chair for the first few months in order to stabilize the SIG. _____________________________________ Releases in the most recent quarter (or most recent release, if none in that quarter) The SIG is not yet creating builds or publishing releases, but we hope to do so in the next quarter. _____________________________________ Health report and general activity narrative. The SIG has had two public meetings since approval, each with roughly 40 attendees representing at least 8 separate organizations. We feel this is a good start at corporate community diversity but will continue to work toward a community-driven project that is not dominated by Red Hat - this is intended to be a community effort with contributions and shared benefits from all participants. One notable participant is the Automotive Grade Linux project (AGL). Also noted are several OEM automakers and a few tier-1 suppliers, so interest is clearly piqued. Several RH employees are working on the first contribution to the project as well as the infrastructure required to build and test it. There is confidence we will be building software in Q4 and hope to have an initial release of an Automotive CentOS variant in Q1 2022. _____________________________________ Issues for the board to address, if any None, keep up the excellent work :) Jeffrey "Jefro" Osier-Mixon | jefro(a)redhat.com Red Hat Office of the CTO | Sr. Principal Community Architect, Automotive

1 1

Contributor documentation: to link between sites or all-in-one?
by Tomas Tomecek 28 Sep '21

28 Sep '21

Hello, we're interested in hearing your feedback, the CentOS community, as well as my Red Hat colleagues. Within our team (packit, context - source-git repos and workflow) we've recently discussed what would be the preferred way of structuring documentation for the source-git workflow. The thing is that the workflow would be available in Fedora, CentOS Stream (and transitively RHEL) while having some common documentation hosted in our project's documentation. That causes fragmentation and the need to link between various sources. I'd like to hear what are your preferences: 1. Have everything on the same site 2. Link between sites and document only specifics to an ecosystem Both of these have pros and cons: * duplicate content vs. linking between sources * everything on the same place vs. the need to access multiple sources * the need to automate the publication process * translate documentation sources between various formats * maintenance burden for the duplicate or fragmented content Right now we have some documentation available here https://docs.centos.org/en-US/stream-contrib/contributing/source-git/ while the technical details live on https://packit.dev/source-git Is this fine or should we improve? The feedback we got so far was to unify it in a single place so I wanted to open up a discussion to hear more. Thank you for your time, Tomas

6 8

Reminder: CentOS Dojo in 2 weeks
by Rich Bowen 24 Sep '21

24 Sep '21

The October online CentOS Dojo will be happening in just 2 weeks. Registration and details are available at https://wiki.centos.org/Events/Dojo/October2021 Registration is FREE. We will have TEN presentations: Thursday, October 7th: (All times in UTC) 15:00 Board of Directors AMA 16:00 What does Red Hat Want? Brian Exelbierd 17:00 State of EPEL on CentOS, Troy Dawson 18:00 Modules - Love/Hate relationship, Alex Baranowski 19:00 Building a high-performance remote desktop with CentOS 8 Stream on Amazon EC2, David Duncan Friday, October 8th 15:00 CentOS Stream and meeting the user requirements of Public Cloud, David Duncan 16:00 Kmods SIG Introduction, Jonathan Billings and Peter Georg 17:00 Hyperscale SIG update, Davide Cavalca 18:00 CentOS Automotive, Jeffrey Osier-Mixon 19:00 Stable AND Cutting Edge: CentOS Stream Deployment in a High Performance Computing Environment at Facebook AI Research, Chris Bray We hope to see you there! --Rich

1 0

[Storage-SIG][BugReport] ceph-common broken dependencies on CentOS Stream 8 / ppc64le
by Sandro Bonazzola 22 Sep '21

22 Sep '21

Hi, oVirt CI started to report the following error: Error: Problem: package ceph-common-2:16.2.6-1.el8s.ppc64le requires libpmemobj.so.1()(64bit), but none of the providers can be installed - cannot install the best candidate for the job - package libpmemobj-1.9.2-1.module_el8.4.0+806+82bbed84.ppc64le is filtered out by modular filtering - package libpmemobj-1.9.2-1.module_el8.5.0+756+4cdc1762.ppc64le is filtered out by modular filtering Can you please have a look? Thanks -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

2 1

Stream 9 and dnf-automatic
by Patrick Riehecky 19 Sep '21

19 Sep '21

I've been thinking about the defaults in CentOS Stream 9 and wanted to chat about the workflows of the system. I'd like to make the following proposal to see what people think about it: * add `dnf-automatic` to comps.xml @BASE as a "default" package * set `dnf-automatic-install.timer` to enabled via `system-preset` similar to `90-default.preset` Before imminently saying "No, absolutely not" lets look at the workflow options: When setting defaults for updates, there are a few choices: * do not apply * notify the user/admin * apply and notify the admin * apply but do not notify The "apply but do not notify" option feels like a non-starter to me. Silent system changes are not good. The current default in CentOS Stream 8 is "do not apply". I've no interest in changing CentOS Stream 8 on this front. # I'd like to ask, is this a good default? For professional admins with a clear policy on testing and scheduling updates, I believe it is a good default. For novices who may not have these processes and procedures in place, I believe this is not a good default. For these folks I'd recommend "apply and notify the admin". # Why change? I'd like to ask a specific question: 48 hours after the release of update packages for Heartbleed or ShellShock, how many CentOS systems in - in their default configuration - installed the updates? Or perhaps a more pointed question, how many folks running EL7 still haven't applied those patches? If the default was "apply and notify the admin", we'd be confident that most folks out there are patched. The default state would generally result in more secure hosts as the updates get applied. Stream 9 is a continuous delivery OS but, if folks don't apply the updates, are they delivered? The current recommendations from the scap-security-guide are: - install and enable dnf-automatic - configure dnf-automatic to apply updates - set a location for `root`'s email via /etc/aliases This is an "apply and notify the admin" workflow. Scientific Linux defaults to "apply and notify the admin". The SL community is comfortable with this default. # Why is the default "do not apply"? As I see it there are basically a few options: A) any change to the system state creates risk of unplanned outage/bugs/behavior changes. B) as a community we trust system admins to "do the right thing" for their environment. C) if we publish a buggy update and it gets applied by default, that isn't great for our reputation. Argument (A) is really strong. Sites with a clear policy on testing and scheduling updates have those policies explicitly because of these risks. To be clear, I like and support those policies. Everyone should have them. But not everyone does. I think Argument (B) can bend in any direction. If we can trust an admin to "do the right thing" and install updates on a schedule of their choosing, can we not also trust them to add `systemctl disable dnf-automatic-install.timer` to their kickstart/puppet/ansible/etc? As a default, but - not mandatory package - it could also be excluded with `-dnf-automatic` in the `%packages` section. I'm not sure that Argument (C) is terribly strong. A giant botnet of unpatched hosts isn't great either. I'm not sure that is our responsibility, but "safer defaults" feels like a good call. # Further reading https://fedoraproject.org/wiki/AutoUpdates#Why_use_Automatic_updates.3F https://github.com/ComplianceAsCode/content/issues/5180

4 4

Pre-release version of CentOS Stream 9.
by Thomas Stephen Lee 16 Sep '21

16 Sep '21

Hi, How do we go about installing a pre-release version of CentOS Stream 9 ? Thanks --- Lee

5 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel September 2021