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
_______________________________________________
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
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
TL;DR: We have postponed the upcoming Dojo at Facebook, and are
carefully watching the situation to determine any other event
participation in the coming months.
Due to the developing situation with the Corona virus and COVID-19, we
have made the decision to postpone our upcoming CentOS Dojo that was
scheduled to occur at Facebook on April 24th. Details of that event are
here - https://wiki.centos.org/Events/Dojo/Facebook2020 - and will be
updated once a new date has been selected.
Other upcoming events are still scheduled to occur, as they are farther
out. The next scheduled event will be at CERN on October 23rd, and we
will update details as we get closer. Details for that event are
available at https://wiki.centos.org/Events/Dojo/CERN2020 and the call
for presentations is still open.
Our planned booth presence at other upcoming events has been canceled
for the foreseeable future, and we will update our event listing at
https://wiki.centos.org/Events once the world situation improves and
travel is once again feasible. There are several other proposed Dojos in
the works at this time, but we are not going to publish any details
until the epidemic crisis has passed.
Thank you for your patience and understanding, and we'll send updates
here once things become clearer.
--
Rich Bowen - rbowen(a)redhat.com
@CentOSProject // @rbowen
859 351 9166
[These are publishing a little late, I got busy and fell behind partially because the
agenda/minutes process has multiple steps where blockages occurred. I'll keep working
to improve the underlying process to make the production of these agendas and minutes
more reliably consistent.]
https://blog.centos.org/2020/03/minutes-for-centos-board-of-directors-2020-…
On 2020-02-12 the CentOS Board of Directors met and discussed several ongoing efforts
across the Project.
The opening discussion was around the new work to evolve the project logo and branding
identity being conducted in open channels. Overall the Directors really liked the
direction the effort is going and were quite pleased with the open nature of the
process. What is needed to bring a conclusion and present a final design for the Board’s
approval is the completion of the open design discussion and decision process to be
conducted in centos-devel.
As the Board is working on adding new Directors and improving governance and transparency,
there is an open discussion around the possibility of having a face-to-face meeting of
the Board in 2020. This ideally would include an additional day of interactions with other
project leadership. One idea floated was to conduct this prior to the CentOS Dojo being
planned at CERN in October 2020. At the time of this writing, it is unknown if this Dojo
will be affected by COVID-19 related or other travel restrictions.
On another topic, in addition to the focused resources of the Community Platform
Engineering (CPE) team that supports the CentOS Project in technical ways, Karsten gave
a brief explanation of how the Community Architects from the Red Hat Open Source Program
Office (OSPO) are in support of the project, specifically Rich Bowen on the community side,
Brian Exelbierd on the business interaction side, and Karsten Wade on the strategic and
visionary side.
>From the Brussels Dojo, Karsten gave a report out about how he had a meeting room for
one-to-one discussions with community members. These discussions were an invitation to
talk about what works and doesn’t work for users and contributors around the project; an
open office hours to hear out anything. It also served to help get an idea of how and why
people use CentOS as a platform. This work is to help inform the CentOS 2020 open goals
discussion now underway.
In support of these efforts, the Board came to the following decisions, resolutions, and
agreements:
1. Logo redesign
1. AGREED: Board is requesting Tuomas to lead the discussion on centos-devel toward
creating the final /branding redesign proposal for the Board to give final approval
on. This process should follow an open decision process of inviting participation,
hearing out other ideas, and taking and incorporating feedback on the existing design
ideas into the final plan. All this can be done over a reasonable time period of four
to eight weeks, so that a decision can be reached that has an opportunity to include
voices from across the community.
2. Board face-to-face
1. AGREED: Board will watch the travel situation with an eye toward deciding yay/nay
on the face-to-face as the June timeframe approaches.
2. ACTION: Board will request RIch Bowen to coordinate with the Board Secretary on plans
for adding meetings around the CERN Dojo.
3. Consent items
1. Adopt minutes from 2020-01-08 meeting
2. Noting that Fabian Arrotin has resigned his role as a CentOS Project Director as of
October 2019.
4. Rolling (last from 2020-01-08):
1. Any other topics aka What other things do you want on our master initiatives list?
2. Stepping-up our meeting norms
3. Transparency initiatives
Present at the meeting:
* Ralph Angenendt
* Jim Perrin
* Mike McLean
* Karsten Wade (Secretary)
* Johnny Hughes
--
Karsten Wade [he/him/his]| Senior Community Architect | @quaid
Red Hat Open Source Program Office (OSPO) : @redhatopen
https://community.redhat.com | https://next.redhat.com | https://theopensourceway.org
gpg: AD0E0C41 | https://red.ht/sig
Earlier this month this was a report that softhsm was available but not
installable in CentOS 8 due to a "No available modular metadata for
modular package" error. The solution was to enable the idm:DL1 module,
but my understanding is that modular packages shouldn't be visible while
their modules are disabled (this seems to be the behaviour in RHEL 8).
Looking in
http://mirror.centos.org/centos/8/AppStream/x86_64/os/Packages/ there
are two versions of softhsm in the AppStream repository:
* softhsm-2.4.0-2.module_el8.1.0+253+3b90c921.x86_64.rpm
* softhsm-2.4.0-2.module_el8.1.0+265+e1e65be4.x86_64.rpm
The repository's modules.yaml file only describes one version of the
module, idm:DL1:8010020200121181805:4a0acb9a:x86_64, which owns the
newer package. When idm:DL1 is enabled this masks the older softhsm
version but when it's disabled (the default) the newer package is
removed from view, and with no repository metadata to indicate that the
older softhsm is part of a module it effectively becomes an ordinary
member of the AppStream repository.
So "dnf install softhsm" offers two different package versions based on
whether or not idm:DL1 is enabled, instead of failing with "Error:
Unable to find a match" when the module is disabled.
You can see a similar thing with the go-toolset module. It's enabled by
default and disabling it should hide all of its packages. Instead,
because a second version has been published (see the two versions of
go-toolset, golang, etc at the earlier URL), disabling go-toolset makes
the previous versions of all the packages appear as ordinary members of
the AppStream repository.
I found https://bugs.centos.org/view.php?id=16808 from around the time
of the 8.0 release querying the lack of older version data, and have
commented on it, but I wanted to confirm that I haven't misunderstood
the expected behaviour. For example, if nodejs:12 receives an update
and the earlier package versions drop out into the main AppStream
repository it seems that this might cause conflicts for someone
installing nodejs from a third party repository, even if they've
disabled nodejs:12.
---
title: CPE Weekly status email
tags: CPE Weekly, email
---
# CPE Weekly: 2020-03-06
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 Minimal Compose is being worked on currently for F32 beta
### Data Centre Move
* Please start to plan for 2-3 week outage of communishift starting
2020-04-12 to allow for the move
* Due to the data centre move, we cannot get a new box to run odcs-backend
https://pagure.io/fedora-infrastructure/issue/8721
* We are also scoping the work required for 'Minimum Viable Fedora' -
here is the link to the mail as a refresher of what to expect, and
what not https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapr…
Our move dates are as follows:
* Move 1 April 13 to IAD2 (essential hardware)
* Move 2 April 13 to RDU-CC (communishift)
* Move 3 May 11 to IAD2 (QA equipment)
* Move 4 June 1 to IAD2 (anything and everything else)
### AAA Replacement
* Sprint 5 will see the team focusing on integration with FASJSON API
and 2FA token
* We have also decided to postpone testing of the new solution until
post data centre move to make sure it is
* As always, check out our progress on github here
https://github.com/orgs/fedora-infra/projects/6
### CI/CD
* Monitor-Gating: Blocked in staging because F32 isn’t branched off
there yet (Koji, Bodhi, PDC, https://pagure.io/releng/issue/9293)
* Automatic Release Tags and Changelog: Ongoing Devel-list thread here
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
* The team have moved to Jitsi video conferencing with interested
community members (ngompa, clime, mboddu, mhroncok) about the
different approaches to automatic release tags. Result: Approach
considering existing EVRs most palatable (over <#commits>.<#builds>).
* We now have a more official looking repo:
https://pagure.io/Fedora-Infra/rpmautospec
* The team also created implementation details and roadmap:
https://hackmd.io/2iQUWeLdR1uTSJ6WL2JqBA
### Sustaining Team
* Old cloud is now officially retired
* Bodhi XSS vulnerability patched
* The team are also looking to prepare a Bodhi 5.2 release
* Fedora Minimal Compose (Use ODCS to trigger test composes)
* The team are also scoping the Mbbox upgrade and Task breakdown
https://github.com/fedora-infra/mbbox/projects/1
* Support community members helping with Badges outage
* The teams has started a conversation about Infra Ticket prioritization
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapr…
## Docs
### Misc Updates/Review Requests
* Initial f32-updates-testing push is fixed
https://github.com/fedora-infra/bodhi/issues/3936
* Fixed perms on f32 ostree to finish updates pushes
* Anitya tests are fixed
https://github.com/fedora-infra/anitya/commit/8fe224dbc6b8071f5c5e6f11abe15…
* Failing tests in the-new-hotness being resolved
https://github.com/fedora-infra/the-new-hotness/pull/273
* Please review Packit integration in the-new-hotness
https://github.com/packit-service/packit/issues/689
* Please review KeepassXC flatpak issue
https://pagure.io/flatpak-module-tools/issue/6
* Please review Jms-messaging-plugin reviews
https://github.com/jenkinsci/jms-messaging-plugin/pull/162
## CentOS Updates
### CentOS
* Ppc64le kickstarter added for CentOS 8
* This will still need to be tested and added in production
* The infrastructure is stable overall though!
### CentOS Stream
* We are now working on the sync-to-git process
* Tycho module was successfully added to Stream in development!
* We are also getting closer to having a contributor workflow model
available for later this year - watch this space!
* We are also working with upstream to generate reports for Stream too
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
Due to the change in the status of Red Hat Summit
(https://www.redhat.com/en/blog/moving-red-hat-summit-2020-virtual-experience),
we have made the decision to postpone the CentOS Dojo at Facebook to a
later date. Many of our potential speakers, as well as many of our
attendees, had travel plans that were dependent on attendance at Red Hat
Summit, and without that event happening they are no longer able to travel.
If you have already registered for the event, we encourage you to stay
registered, so that we have an easy way to contact you about event
updates through Eventbrite.
We do still plan to hold an event at Facebook, but, due to the current
corona virus situation, we are holding off on making any firm plans
until the danger has passed.
We thank you for your patience and understanding, and hope to see you
when we reschedule.
--
Rich Bowen - rbowen(a)redhat.com
@CentOSProject // @rbowen
859 351 9166