devel

devel@lists.centos.org

4 participants
4640 discussions

Last call for video content: CentOS @ Red Hat Summit
by Rich Bowen 25 Mar '20

25 Mar '20

Next month, Red Hat Summit will be happening, as a virtual event. They're expecting 30,000 "attendees", and we're delivering content via videos. If you'd like to present your work in the CentOS project to 30,000 interested people, PLEASE get in touch with me ASAP, and we can schedule a short video interview for inclusion in that event. Any topic is fair game, if it's related to the CentOS project. The deadline for delivering these finished videos is Monday, March 30th, so I really need to hear from you today or tomorrow if we want to make this happen. Thanks! -- Rich Bowen - rbowen(a)redhat.com @CentOSProject // @rbowen 859 351 9166

3 3

CBS Signing process going live this wednesday !
by Fabian Arrotin 25 Mar '20

25 Mar '20

Hi all, After some tests and some feedback from some SIGs , we're happy to announce that we'll go live this wednesday with the new signing process (also covering c8) Per discussion/feedback with some SIGs (or lack of feedback), we locked the following CBS tags : paas7-openshift-origin311-release paas7-openshift-origin-release paas7-openshift-origin13-release paas7-openshift-origin14-release paas7-openshift-origin15-release paas7-openshift-origin36-release paas7-openshift-origin37-release paas7-openshift-origin38-release paas7-openshift-origin39-release paas7-openshift-origin310-release paas7-openshift-common-release nfv7-vpp-1801-release nfv7-vpp-1804-release nfv7-vpp-1807-release nfv7-common-release virt7-ovirt-42-release virt7-ovirt-44-release virt7-kubernetes-19-release virt7-kubernetes-110-release opstools7-perfmon-common-release opstools7-common-release opstools7-sensu-common-release opstools7-sensu-027-release opstools7-sensu-110-release opstools7-fluentd-012-release If you have questions, Thomas and myself will be answering in #centos-devel, should any issue arise. PS : for Trimmed content/EOL, each SIG should start considering announcing content that will go away (to vault and not available to mirror network) -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab

3 4

SIG members: Presentations for the "virtual summit"
by Rich Bowen 24 Mar '20

24 Mar '20

As you may have seen, Red Hat Summit has been converted to a virtual event - https://www.redhat.com/en/summit - and we, the community projects that were to have a presence there - have been asked to supply some of the content for that virtual event. This is an opportunity to tell a wider audience about what we're doing in this project. In particular, I invite SIG members to provide an update, in the form of a video/slide presentation, about what your SIG has been working on, what's planned for the coming year, and how new participants can get involved. If you are involved in a SIG, please discuss this with the other participants, and put together 2-5 slides about the above topics, and designate someone who can deliver this content. Get in touch with me, and we can schedule a time to record this presentation via Google Meeting, or Bluejeans. I *think* that the "virtual summit" will be async, rather than live presentations, but that is still being figured out at this time. Meanwhile, gathering the content and identifying the speakers is an important first step. If you're interested in presenting some other (ie, non-SIG related) content, please do get in touch with me. Thanks! -- Rich Bowen - rbowen(a)redhat.com @CentOSProject // @rbowen 859 351 9166

1 1

CBS mash repositories going away next wednesday
by Fabian Arrotin 23 Mar '20

23 Mar '20

Tied to the previous announce, the new signing system will not depend on cbs-content-control, which itself was using repositories prepared by mash. Those repositories, while normally not meant to be consumed, will so go away. So all https://cbs.centos.org/repos/* will disappear next wednesday (FWIW) -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab

2 2

CPE Weekly: 2020-03-21
by Aoife Moloney 21 Mar '20

21 Mar '20

--- title: CPE Weekly status email tags: CPE Weekly, email --- # CPE Weekly: 2020-03-21 Background: The Community Platform Engineering group is the Red Hat team combining IT and release engineering from Fedora and CentOS. Our goal is to keep core servers and services running and maintained, build releases, and other strategic tasks that need more dedicated time than volunteers can give. For better communication, we will be giving weekly reports to the CentOS and Fedora communities about the general tasks and work being done. Also for better communication between our groups we have created #redhat-cpe on Freenode IRC! Please feel free to catch us there, a mail has landed on both the CentOS and Fedora devel lists with context here. ## Fedora Updates * Fedora 32 Beta is released * Pungi configs created * RC composes ran * Synched to stg * Checksums signed * Pushed to mirrors * F32 flatpack support added * Silverblue is rebased for f32 - article on proposal to Fedora Magazine https://pagure.io/fedora-magazine-proposals/issue/59 ### Issue FYI's & Request for Review * The team are working on resolving the issues in the staging environment for the packager workflow https://pagure.io/releng/issue/9293 * Help with infra-sig packaging appreciated https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&… * Packit integration in the-new-hotness https://github.com/packit-service/packit/issues/689 * KeepassXC flatpak issue https://pagure.io/flatpak-module-tools/issue/6 ### Data Centre Move * Communishift will be unavailable from 2020-04-13 until 2020-05-08 * Check out our detailed move shedule here https://hackmd.io/R3EkjzVyTG2TYwQvkfzYrA?sync=&type= ### AAA Replacement * OTP & 2FA authentication is now working! * Fedora messaging is also integrated in the project * As always, check out our progress on github here https://github.com/orgs/fedora-infra/projects/6 ### CI/CD * The koji plugin which is triggered post git checkout has been written and merged in the rpmautospec project * Working on finishing the rpmautospec logic for release and changelog and use it in the koji post git-checkout plugin and hope to achieve the following * Write the koji plugin to add git tags on dist-git (via pagure) upon successful builds * Package rpmautospec as an RPM * Deploy to stg * Links to the WIP issues in the POC * https://pagure.io/Fedora-Infra/rpmautospec/pull-request/15 https://pagure.io/Fedora-Infra/rpmautospec/pull-request/9 https://pagure.io/Fedora-Infra/rpmautospec/pull-request/5 https://pagure.io/Fedora-Infra/rpmautospec/pull-request/7 https://pagure.io/Fedora-Infra/rpmautospec/pull-request/8 https://pagure.io/Fedora-Infra/rpmautospec/pull-request/13 ### Sustaining Team * Mbbox upgrade work * Project is kicked off https://github.com/fedora-infra/mbbox/projects/1 Vagrant environment for operator-sdk ready Initial operator project ready Work on koji-hub CRD started Work on koji-builder CRD started * RabbitMQ has an outage so a new troubleshooting section has been added to the SOP https://fedora-infra-docs.readthedocs.io/en/latest/sysadmin-guide/sops/rabb… ## Docs * Issue created for problems with SELinux documentation in Fedora Quick Fix https://pagure.io/fedora-docs/quick-docs/issue/207 * Build errors updated in the Fedora Defensive Coding Guide https://pagure.io/defensive-coding-guide/issue/7#comment-634123 * F32 release notes being worked on ### Misc Updates/Review Requests * Upgrade pagure and pagure-dist-git on stg * Bugzilla overrides on src.stg landing * Infra-Sig Package Updates * https://bodhi.fedoraproject.org/updates/FEDORA-2020-2c40290717 https://bodhi.fedoraproject.org/updates/FEDORA-2020-2f3ff7bd46 https://bodhi.fedoraproject.org/updates/FEDORA-2020-2c3c3a9e25 https://bodhi.fedoraproject.org/updates/FEDORA-2020-dcb1f11c25 * Jms-messaging-plugin wire support https://github.com/jenkinsci/jms-messaging-plugin/pull/162 * Create 1.0 milestone for Anitya https://github.com/fedora-infra/anitya/milestone/6 * Openh264 Generated the repos Signed the rpms and repodata Sent them to cisco and waiting ## CentOS Updates ### CentOS * Fedora infra images are added to quay.ie for shared library * ppc64le image in testing ### CentOS Stream * Python38 module is running in c8S! * Kernel + VDO has been created for Stream * The team are refactoring the sync2git role and hope to deploy it soon As always, feedback is welcome, and we will continue to look at ways to improve the delivery and readability of this weekly report. Have a great weekend! Aoife Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford

1 0

newer cri-o builds for CentOS 7
by Baptiste Agasse 20 Mar '20

20 Mar '20

Hi all, I try to find a build of cri-o > 1.13 in a repo for CentOS 7. I find some package version that fit this requirement [1] and some builds[2] that are tagged with 'paas7-crio-115-release' but I didn't find any newer version of cri-o than crio-1.11 in origin311 repo [3]. Is there any repo that I'm missing where newer cri-o builds are located ? Have a nice day. Cheers. [1] https://cbs.centos.org/koji/packageinfo?packageID=5695 [2] https://cbs.centos.org/koji/buildinfo?buildID=26497 [3] http://mirror.centos.org/centos-7/7.7.1908/paas/x86_64/openshift-origin311/ -- Baptiste

4 3

Tags structure proposal (and fix) for CBS
by Fabian Arrotin 19 Mar '20

19 Mar '20

When working with Thomas on new signing process, we decided that we'd use Koji/CBS as single source of truth, so new signing process should only query koji/cbs and automatically act when there would be something to do. Creating so a different thread to discuss the koji tags we have. We discovered some inconsistencies and we think that $now would be a good time to fix/move those if needed. The current proposal would be (and most of the existing tags are following that convention) : <sig><dist>-<sig_project>-<sig_project_rel>-<sig_level> If we take an example for Gluster 7 for CentOS 7, built by Storage SIG, that means the following tags : storage7-gluster-7-{candidate,testing,release} The path where new process would automatically push out (to mirror CDN) would be so based on koji tag : mirror.centos.org/{centos,altarch}/<dist>/<sig>/{arch}/<sig_project>-<sig_project_rel>/ Once again, if we take the gluster 7 as an example, that would mean that process would automatically (for -release tag, with three enabled arches), push to those paths (created if needed) : * http://mirror.centos.org/centos/7/storage/x86_64/gluster-7/ * http://mirror.centos.org/altarch/7/storage/aarch64/gluster-7/ * http://mirror.centos.org/altarch/7/storage/ppc64le/gluster-7/ The full path is coming from the koji tag, but we see some issues for some paths/SIGs (like NFV) As we think that it would be good to have confirmations from all SIGs (as they are responsible for content to be pushed out, and also good time to have EOL content removed), we'd eventually "lock" koji tags for which we have *not* received confirmation for final destination path. Other thing we discovered : some SIGs (in the past) have asked for a "common" tag but then have asked (through cbs-content-control) to have content from that common tag to be added in other repo. As we'll *not* use cbs-content-control anymore, the way to deal with this would be : - either we use koji tag inheritance (preferred solution) - or you just "tag-build" yourself when needed from one to the other The advantage of doing this through koji tag inheritance is the following : When you request for some tags, and specify what they would need, nothing else would have to be done and you can just tag-build from -testing to -release to trigger the sign+push to mirrors (while tag-build to -testing first would push unsigned pkgs automatically to buildlogs.centos.org, as usual) Can we ask each SIG Chair to see which projects/releases are still needed and so come back (either in this thread of #centos-devel) Thanks for your collaboration ! -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab

2 1

CentOS for IBM LinuxONE / IBM System Z
by FuLong Wang 19 Mar '20

19 Mar '20

Hello Everyone, I'm from IBM China Development Team and I'm working on a new initiative that plan to enable a "*minimized*" or "full" CentOS operating system on IBM LinuxONE / IBM System Z (s390x architect). The reason why we start this topic is we are trying to contribute to the RDO community with our OpenStack build on LInuxONE. We have successfully finished the build job for OpenStack Train Version on LinuxONE and passed the basic function verification tests recently. Now, we already have a link for worldwide users & fans to reference for their needs. For "official official" contributing to the RDO community, community admin stated that a TripleO CI env is a must for community release criteria and the OpenStack packages need to be built in the CentOS build system which run on s390x arch. So, we turn to here for help, we know CentOS community ever had releases for s390x arch but for whatever reasons finally stopped for update. We want to take this opportunity to enable it up again and therefore want to know about the overall processes, skills required, hardware requirements, manpowers and duration estimated and which parts need IBM's team's input, etc. Our target is to enable at least a *"minimized" CentOS* (which can support the OpenStack CI work), is there a SIG fit for this purpose? or a "full" CentOS with default feature sets. Could anybody kindly give us some clue to start this journey? Thanks everyone in advance! The Howto of OpenStack Train Installation on IBM LinuxONE had been merged to the RDO official website. https://www.rdoproject.org/install/ -- FuLong Wang fulong.wang(a)cn.ibm.com IBM China Systems Lab, Beijing, China _______________________________________________

5 9

New CBS/SIG signing process
by Fabian Arrotin 16 Mar '20

16 Mar '20

Hi all (especially SIG members/contributors) , As announced by Jim some time ago, we wanted to redesign the current signing process that is in place for https://cbs.centos.org for CentOS 6 and 7 (so quite some years now) The goal is to automate as much as possible the workflow, and working for all releases (yeah for CentOS 8 and Stream) Thomas and myself have worked on the following idea and we're now happy with the results (in our Dev environment) : - when someone builds a pkg, and that it's tagged to -testing, koji sends a notification (through koji callback - https://fedoraproject.org/wiki/Koji/WritingKojiCode#Event_Plugin) to a bus - signing machine listens to the bus, process the tag and push directly to buildlogs - when someone tag-build said pkg to -release, the node signs it with correct gpg key id (from the SIG), push generated repository (including for debuginfo/src.rpm packages) to mirror CDN As we were working on such automation, we also confirm that if one uses "untag-build", the same rule applies : it triggers automatically koji to reprocess the tag/repo and so removes the pkg from mirror (we got some requests for that in the past) The process so would work 24/7, and also have monitoring built-in (so that we can detect - the infra team - when something doesn't work, and so we can still process the tag again) We recently upgraded cbs.centos.org to newer koji version that permits some of the needed operations for this to happen. At this stage, we are just missing the SIG GPG private keys, but we were promised to have those this week. We don't have any ETA yet for the migration to new signing system, but we were thinking about such plan: - deploy and configure (automatically) new signing node (this week) - import GPG keys in the new system and validate that we can sign (when we get those) - changes some flags/parameters on tags on cbs.centos.org (this week) Once we have this in place, we'd like to start validating the signing process but *not* pushing to mirror CDN (yet). Same for the bus : we'd like to process all tags in advance as we'll have to import RPM signatures back in koji/cbs. After full validation, we announce that new system would be fully in place, and kojihub restarted with the notification plugin. From that point, the system would be fully operational and so when SIG members would build/tag pkgs, that would trigger the push (and signing if needed for -release tag) Worth knowing that with the update to some components in the chain, the directory layout will change a little bit (like people are already used to if using Fedora and Epel) : the Packages will be splitted by first letter. Here is an example from our testing : └── storage └── x86_64 └── gluster-7 ├── Packages │ ├── g │ │ ├── glusterfs-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-api-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-api-devel-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-cli-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-client-xlators-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-cloudsync-plugins-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-devel-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-events-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-extra-xlators-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-fuse-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-geo-replication-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-libs-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-rdma-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-resource-agents-7.2-1.el7.noarch.rpm │ │ ├── glusterfs-server-7.2-1.el7.x86_64.rpm │ │ └── glusterfs-thin-arbiter-7.2-1.el7.x86_64.rpm │ ├── p │ │ └── python2-gluster-7.2-1.el7.x86_64.rpm │ └── u │ ├── userspace-rcu-0.7.16-3.el7.x86_64.rpm │ └── userspace-rcu-devel-0.7.16-3.el7.x86_64.rpm └── repodata ├── 047503df3313d596e14a1a0d097b6c2261b26690000ecd4260d212a6f5e5632d-other.sqlite.bz2 ├── 34c1f5dd954099816d6cce289e52f96e61cc2e6430e13072194e35c063b0e3da-primary.xml.gz ├── 6293e07e4c5a7acc2c610beb5acb84b996329ef3c6d61c03e375f2afc6a71536-filelists.sqlite.bz2 ├── 6f89e8b43fb7e384f86f041c4de84d9afeb15dca981559b15230cb48887095db-other.xml.gz ├── bef236563d185417fbda48e3b4dd1d62714d1af2b7a7d6dc1a7213af5de1aa9b-primary.sqlite.bz2 ├── fb66c148e8e2738bd5d19b88d1b3507b0383aaab0938de3809b399babb1a0b44-filelists.xml.gz ├── repomd.xml └── repomd.xml.asc From a usage perspective that will not change the way pkgs can be consumed, as repodata will always be at the right place, but in the case of SCLs that will mean no subdirectory like before, but instead just same "first letter" name (while repodata will be global) So in the current stage, we'd like to deploy and fully validate the signing setup and we'll announce on this list when we'll fully switch to new system. Also worth noting that with the new system in place, in theory we'll *not* use the old cbs-content-control git repo (as we'll query automatically koji for tags, enabled architectures, etc) so tagging to -testing and -release should trigger automatically the "push to mirrors" step If you have questions, comments, feel free to answer in this thread and/or #centos-devel on irc.freenode.net Kind Regards, Thomas and Fabian -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab

8 18

Trimming/Removing EOL SIG content from mirror.centos.org
by Fabian Arrotin 16 Mar '20

16 Mar '20

Hi all SIG members, When working in our "Staging" environment while validating the new signing process (still to be announced when fully in use/prod), we detected some SIGs having multiple variants/versions of their packages. Just one example (already discussed with Niels and Kaleb in #centos-devel but let's just this one a example): Gluster has multiple versions still listed on mirror.centos.org : http://mirror.centos.org/centos/7/storage/x86_64/ As the new process would automatically decide where to push content based on koji/cbs tag name, we found the interesting corner case of gluster312. The CBS tag is storage7-gluster-312-release and so new process would push to centos/7/storage/x86_64/gluster-312/ instead of http://mirror.centos.org/centos/7/storage/x86_64/gluster-3.12/ (see the diff betwen koji/cbs tag and the final path/destination) It seems that only Gluster was impacted for older releases, while it should be good for new releases (tested). But so that brings the following request : can you come with a list of EOL repositories that you'd like us to trim/remove from mirror.centos.org (they'll be archived to vault.centos.org) ? Doing that at the same time as we launch the new signing/push process would be a good idea. Thanks a lot in advance for your collaboration ! -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab

5 9

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