Hi everyone,
Welcome to the CPE team weekly project update mail!
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.
For increased communication between our communities, we have created
#redhat-cpe on Freenode! Please feel free to catch us there, a mail
has landed on both the CentOS and Fedora devel lists with context
here.
Note:
This document is currently built from individual reports rolled into a
google document which we edit and copy into a final document. We are
aware that this causes problems with some email readers, and are
working on a method to make this less problematic.
High Level Project Updates:
Fedora:
F31 was released on Tuesday 29th October!
https://fedoramagazine.org/announcing-fedora-31/
F31 documentation was also released. Fedora 31 websites had a harder
release, but it is clearer to parties involved the amount of work
which was done in the background every release.
Fedora Infrastructure freeze ended and so changes to infrastructure
can occur until the F32 Beta in about 3 months.
Congratulations to everyone in the Community whom were involved with
the release, onwards to F32 :)
Rawhide Gating:
A call to arms email has been sent asking for testers for multi build
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
Single build workflow is working again and is aligned with multi-build
workflows also
https://bodhi.stg.fedoraproject.org/updates/FEDORA-2019-3d6e95211e
Update for the multi-build workflow needs to be created with autotime
on, otherwise the update will not get pushed
https://bodhi.stg.fedoraproject.org/updates/FEDORA-2019-90b8bce568
Overview page of the remaining blockers and dependencies organized at:
https://hackmd.io/Gbuu9JOPR--Y2yNCBEYI5A?viewCi.centos.org is still not using fedora-messaging
Ci-resultsdb-listener with fedora-messaging and support for the new
messages format is not deployed in production yet
repoSpanner
Developed another experimental patch that got us an ~83x speed up.
Got 122% performance patch merged.
Worked with smooge to get a repoSpanner cluster deployed on realistic
cross-datacenter hardware.
repoSpanner is still extremely slow when all three DCs are used. Est.
58 minutes to push Bodhi into it, even with the 83x speedup patch. The
team is investigating a solution.
Application Retirements
Elections: Blocking issue was fixed
https://pagure.io/fedora-infrastructure/issue/8253
Fedocal : jlanda started to work on communishift port
https://pagure.io/fedora-infrastructure/issue/8274
Nuancier: Benson Muite is now working on OIDC authentication - Thank you Benson!
Fed-msg: fedmsg-logger equivalent for fedora-messaging
https://pagure.io/releng/pull-request/8940
CentOS:
Cbs.centos.org migration
Started planning for how to make community builds available with EL8
Deploying a new koji host that will be used for cbs.centos.org migration
Migrated following services from puppet configuration management:
https://feeds.centos.org (now under ansible, covering CentOS Stream/8)
https://planet.centos.org (now under ansible)
Continuing conversion of further puppet roles to ansible
CentOS CI
Added CentOS 8 and CentOS Stream in cico
Updated python-cicoclient to support CentOS 8 and CentOS Stream
Comments? Suggestions? Feedback? Let Us Know!
Have a lovely weekend!
Aoife
--
Aoife Moloney
Feature Driver
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
Hi all,
Today jlanda, austinpowered and mizdebsk discussed about ticket
https://pagure.io/fedora-infrastructure/issue/8157 in #fedora-admin and
came up with a few questions on how to implement that solution that I think
would be nice to share with the wider group.
There are basically 2 possibility :
1 - We run ansible-report as a pre-commit hook
This means that ansible-report will be run locally before a contributor
commit a change. This is not ideal since our contributor are running all
kind systems (rhel, fedora, windows ?) so having something that work well
for everyone will not be simple. Also this forces our contributors to
install ansible-report locally.
2 - We run ansible-report as a pre-receive hook
This means that ansible-report is run on batcave01, but we cannot run
ansible-report just on a commit, we need to run the tool against the full
repository every time. That involve making a clone of the repo applying the
changes in the incoming commit, then run ansible-report on that repository.
This has also a few disadvantages, first we first need to clear all the
errors reported by ansible-report in our repo before we enable the hook
otherwise all commits will be rejected. It will also slows down every
pushes (time to clone, apply patch, run the tool).
Do people have other ideas ? Is this change worth the trouble ?
Thanks