devel

devel@lists.centos.org

16 participants
4590 discussions

ANN: Hyperscale (GNOME/KDE) Workstation snapshot 20211001 LiveDVDs
by Neal Gompa 02 Oct '21

02 Oct '21

https://lists.centos.org/pipermail/centos-devel/2021-June/077079.htmlHello all, As I announced back in June[1], the CentOS Hyperscale SIG started producing an experimental Hyperscale Workstation Spin to showcase the technologies we're working on to the broader community. Today, I'm pleased to announce we've refreshed the images we released at the end of July[2]. Like that release, this one includes both GNOME and KDE Workstation variants. The spins are available here: * GNOME ISO: https://d2r1r30d0ahkv5.cloudfront.net/CS8-HS-GNOME-LIVE-20211001.iso * KDE ISO: https://d2r1r30d0ahkv5.cloudfront.net/CS8-HS-KDE-LIVE-20211001.iso * SHA512 checksums: https://d2r1r30d0ahkv5.cloudfront.net/CS8-HS-LIVE-20211001-CHECKSUMS We also now have the latest version of the spins for download at the Hyperscale SIG website: https://sigs.centos.org/hyperscale/spins/workstation/ Aside from being a general package content refresh, there is a notable fix: * PackageKit now is able to resolve CentOS repositories. Since CentOS repositories use non-standard DNF vars in the repository paths, PackageKit was not able to resolve them. This bug was reported over a year ago (and fixed in PackageKit upstream!), but despite having a patch to fix it, it has not been fixed, so we now ship a patched PackageKit to resolve the problem. The Red Hat bug describes the issue and has a fix for it included: https://bugzilla.redhat.com/show_bug.cgi?id=1847124 The remaining issues are expected to be the same as the previous release[2]. If you find any other issues, we would definitely love to hear about them! We have a dedicated issue tracker for Hyperscale spins where we would appreciate bugs to be reported: https://pagure.io/centos-sig-hyperscale/spin-bugs We hope you enjoy it as much as I enjoyed making this! Thanks and best regards, Neal (on behalf of the CentOS Hyperscale SIG) [1]: https://lists.centos.org/pipermail/centos-devel/2021-June/077079.html [2]: https://lists.centos.org/pipermail/centos-devel/2021-July/077170.html -- 真実はいつも一つ！/ Always, there's only one truth!

1 1

CPE Weekly Update - Week of Sept 27th
by Vipul Siddharth 01 Oct '21

01 Oct '21

Hi everyone, This is a weekly report from the CPE (Community Platform Engineering) Team. If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on libera.chat (https://libera.chat/). There was a hiatus for some time, expect this weekly from now on! If you wish to read this in rendered markdown, check the post on discussion.fedoraproject.org: https://discussion.fedoraproject.org/t/cpe-weekly-update-week-of-sept-27th-… # Highlights of the week ## Infrastructure & Release Engineering Goal of this Initiative ----------------------- Purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work. It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.). The ARC (which is a subset of the team) investigates possible initiatives that CPE might take on. Update ------ ### Hardware Updates * Warranty renewal season for both Fedora and CentOS Infra, which means we are looking at the hardware that needs attention. ### Fedora Infra * Infra and Releng team is working with other initiatives team members to handover maintenance tasks * Started moving forward again on updating our dnssec keys * Issues with openqa-x86-worker04 machine ongoing * Planning a mass update/reboot cycle next week tentatively * 66 issues open (many to close as the freeze lifted) ### CentOS Infra * https://sigs.centos.org announced on the centos-devel list * Updated ci.centos.org Jenkins to comply with security compliance * Collaboration with Stream team for infra tasks (including for beaker/ftp) * Business as usual * New tags in cbs/koji (automotive, cloud) * New projects on git.centos.org ### Release Engineering * Fedora 35 Beta out the door! Freeze ended ## CentOS Stream Goal of this Initiative ----------------------- This initiative is working on CentOS Stream/Emerging RHEL to make this new distribution a reality. The goal of this initiative is to prepare the ecosystem for the new CentOS Stream. Updates ------- * Working on Content Resolver buildroot logic integration * Metalinks for CentOS Stream 9 mirrors works now * An updated centos-release package exercising the new mirror infra is built, we expect it to be composed in the next couple of days * Starting some investigations to help maintainers work with GitLab * Reworking some of the protocols that we announce internally for our composes (Beaker needs to pull the composes via FTP or tftp) ## Datanommer/Datagrepper Goal of this Initiative ----------------------- These apps are currently used to retrieve historical information about messages on the fedmsg bus and add them to a Postgres database. Datanommer reads-in messages from the bus and stores them in the database and Datagrepper exposes the messages in the database via an API with different filtering capacities. We want to upgrade these applications to use fedora-messaging and increase the performance of the applications for users. Updates ------- * Import script is still running, the ETA of ~2 months seems to be confirmed * We’re doing the finishing touches to code ## Metrics for Apps on OpenShift Goal of this Initiative ----------------------- The project team will deliver on the installation of newest OpenShift in Fedora infra to be then configured with prometheus so applications can be hooked into this service and can be monitored and metricized through this tech stack for more comprehensive understanding of app behaviour, performance and troubleshooting. Updates ------- * A lot of work in docs - SOP docs merged https://pagure.io/infra-docs-fpo/pull-request/8 * We’ve enabled the user-workload-monitoring stack on the staging cluster, and began documenting it * We’ve disabled the default permissions that users get when they login on the staging cluster and started documenting that too * A few things are not quite right like network interfaces, but we have the basic production cluster up and running * Working to get the web console working, but in the meantime can use the CLI on the os-control01 node: https://console-openshift-console.apps.ocp.fedoraproject.org/ ## DNF Counting Goal of this Initiative ----------------------- The DNF Counting project will enhance the currently existing program that captures a ‘countme’ value from computers running Fedora weekly. There are multiple scripts running from a server which parses the data into a csv file for graphing and displaying trends that had been misbehaving a lot. This program gives a good indication for how many computers use Fedora so the project team will work on improving these scripts and the program overall to make it a more reliable and maintainable solution. Updates ------- * Finishing off last tests * More deployment cleanup * Investigate why our cronjobs are so noisy (ongoing) * Ongoing work on documentation: https://docs.fedoraproject.org/en-US/infra/sysadmin_guide/dnf-counting/ Kindest regards & on behalf of the CPE team, -- Vipul Siddharth He/His/Him Fedora | CentOS CI Infrastructure Team

1 0

[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

Board AMA, #centos-meeting, Wednesday, 14:00 UTC
by Rich Bowen 15 Sep '21

15 Sep '21

Reminder: On Wednesday, September 15th, at 14:00 UTC, (some of the) the board of directors will be available in #centos-meeting on Libera.chat IRC network, for your questions. This is a good time to ask about the board meeting that happened last week. (Today has gotten away from me, but I will attempt to post the meeting minutes tomorrow morning) or, really, any board-level topic. --Rich

1 3

Schedule and Registration for CentOS Dojo
by Rich Bowen 07 Sep '21

07 Sep '21

The (tentative) schedule and registration for the upcoming CentOS Dojo are now available. Join us for two days of technical and community talks. Details at https://wiki.centos.org/Events/Dojo/October2021 Registration is free, and the event is online. --Rich

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel