CPE Weekly Update – Week of November 29th – December 3rd
by Lenka Segura
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/).
If you wish to read this in form of a blog post, check the post on
Fedora community blog:
https://communityblog.fedoraproject.org/cpe-weekly-update---week-of-novem...
(available soon)
# 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
------
### Fedora Infra
* Tracked down a annoying s390x qemu bug in f35 qemu
* Gitlab saml2 auth hooked up (https://gitlab.com/groups/fedora)
* Got bugzilla2fedmsg cert renewed.
* Lots of misc small tickets
### CentOS Infra including CentOS CI
* cbs/koji:
* Fixed issue for builds with large file descriptors needs
(https://pagure.io/centos-infra/issue/527)
* Tested an “image-build” and we’ll document how SIGs will be able to
build appliances/images through cbs (
https://pagure.io/centos-infra/issue/535)
* New TAGs (BAU)
* Sponsored infra: added zabbix macros through ansible to trigger alert on
higher
BW consumption
(
https://github.com/CentOS/ansible-role-zabbix-agent/commit/be532e32758b2d...
)
* WIP (RFE) : building DuD .iso images through cbs pipeline (
https://pagure.io/centos-infra/issue/418)
* WIP/proposal : discussed a rewrite of SIG Guide and move from wiki to
sigs.centos.org
### Release Engineering
* Fedora 33 is EOL as of 30.11
## 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
-------
* ELN compose tracker is deployed
## OSCI - Distrobaker monitoring
Goal of this Initiative
-----------------------
This initiative is to improve the Distrobaker monitoring to monitor
side-tags and module builds.
Distrobaker is a service which rebuilds the CentOS 9 Stream Koji builds for
RHEL 9 in Brew.
Updates
-------
* Just getting familiar with the codebase, starting to make minor changes
and check outputs.
## CentOS Duffy CI
Goal of this Initiative
-----------------------
Duffy is a system within CentOS CI Infra which allows tenants to provision
and
access bare metal resources of multiple architectures for the purposes of
CI testing.
We need to add the ability to checkout VMs in CentOS CI in Duffy. We have
OpenNebula hypervisor available, and have started developing playbooks which
can be used to create VMs using the OpenNebula API, but due to the current
state
of how Duffy is deployed, we are blocked with new dev work to add the
VM checkout functionality.
Updates
-------
* API exposes database models (the gift that keeps on giving, almost done,
any year now!)
* Interfacing with OpenNebula to hand out virtual machines
## EPEL
Goal of this initiative
-----------------------
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest
Group that creates,
maintains, and manages a high quality set of additional packages for
Enterprise Linux, including,
but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific
Linux (SL), Oracle Linux (OL).
EPEL packages are usually based on their Fedora counterparts and will never
conflict with or replace
packages in the base Enterprise Linux distributions. EPEL uses much of the
same infrastructure as Fedora,
including buildsystem, bugzilla instance, updates manager, mirror manager
and more.
Updates
-------
* EPEL Steering Committee voted to use plan C for the EPEL 9 rollout.
This means we will finish up EPEL 9 and announce EPEL 9 and EPEL 9 Next
simultaneously.
(https://meetbot.fedoraproject.org/teams/epel/epel.2021-11-24-21.00.html,
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproj...
)
Kindest regards,
CPE Team
2 years, 4 months
adopting python-nnpy?
by Tom Rix
I am working on adding p4 language support to fedora.
One of its packages uses the orphaned python-nnpy.
Builds ok on rawhide, anyone mind if I adopt it ?
Tom
2 years, 4 months
Re: [cfe-dev] Release 13.0.1-rc1 has been tagged
by Tom Stellard
On 12/2/21 06:45, Nemanja Ivanovic wrote:
> Hi Tom,
>
> would it be OK to directly send you git hashes for patches we would like back ported until the bugzilla transition completes?
>
Yes, that's fine.
-Tom
> On Tue, Nov 30, 2021 at 1:08 AM Tom Stellard via cfe-dev <cfe-dev(a)lists.llvm.org <mailto:cfe-dev@lists.llvm.org>> wrote:
>
> Hi,
>
> I've tagged 13.0.1-rc1. Testers can begin testing and uploading binaries.
>
> There is still time to submit fixes for the final 13.0.1. I'll give more
> details about timelines and how to do this once the bugzilla migration is
> complete. Currently, bugzilla is read-only, so we can't submit any fixes
> there.
>
> -Tom
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev(a)lists.llvm.org <mailto:cfe-dev@lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>
2 years, 4 months
F36 Change: ostree native containers / CoreOS layering (System-Wide
Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/OstreeNativeContainer
== Summary ==
Enhance the (rpm-)ostree stack to natively support OCI/Docker
containers as a transport and delivery mechanism for operating system
content.
This is the basis of
https://github.com/coreos/enhancements/blob/main/os/coreos-layering.md
== Owner ==
* Name: [[User:walters| Colin Walters]]
* Email: walters(a)verbum.org
== Detailed Description ==
Having the Fedora ecosystem (from users to release engineering)
maintain tooling that operates on all three of "container images",
RPMs, and OSTree updates is a maintenance burden.
This proposes that:
* The ostree stack is enhanced to support
encapsulating/unencapsulating ostree commits as OCI/Docker images
(DONE)
* rpm-ostree is updated to consume this, while still supporting all
its current features (e.g. per-machine package layering) (DONE)
* We ship e.g. `quay.io/fedora/coreos:stable` and
`quay.io/fedora/silverblue:36` etc.
* We support '''deriving''' new user custom images from these images
* We enhance this tooling to
[https://github.com/ostreedev/ostree-rs-ext/issues/69 support
chunking]
For more details, please see:
* [https://github.com/coreos/enhancements/blob/main/os/coreos-layering.md
CoreOS layering enhancement]
* [https://coreos.github.io/rpm-ostree/container/ rpm-ostree container docs]
* [https://github.com/ostreedev/ostree-rs-ext/ ostree-rs-ext project]
Note that significant effort has been invested in ensuring
compatibility between what exists in ostree today and OCI/Docker
container image "encapsulation". For example, we will continue to
reuse the GPG signature infrastructure on OSTree commits that exists
today - the ostree tooling knows how to verify the signature *inside*
the container image. In the future, we will also likely invest in
container-native signatures.
== Benefit to Fedora ==
* Stronger focus on Docker/OCI as transport for operating system and
applications
* New ability to easily create derived operating system images "server side"
* More benefit from e.g. work on container deltas
== Scope ==
* Proposal owners: Lots of detailed items listed in the rpm-ostree/CoreOS docs.
* Other developers: The "other" here is vague, but certainly
developing this so far has needed cooperation with e.g. the
containers/ organization etc.
* Release engineering: https://pagure.io/releng/issue/10399
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: No
== Upgrade/compatibility impact ==
Each individual edition/spin would need to choose when and how to make
a cutover to containers as a transport. The Fedora OSTree repository
would continue to be maintained until that is finished.
== How To Test ==
See the examples under https://coreos.github.io/rpm-ostree/container/
== User Experience ==
Users of rpm-ostree systems will primarily interact with container images.
== Dependencies ==
Release engineering.
== Contingency Plan ==
* Contingency mechanism: Continue to ship updates via baseline OSTree
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks release? No
== Documentation ==
Already linked above to avoid duplicating it here.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 4 months
CPE takeover Fedora social hour - today!
by Vipul Siddharth
Hey folks,
The Community Platform Engineering team from Red Hat will join us today for
the Fedora Social Hour call. This call would be slightly different from
usual ones – as this time we won’t be breaking any rules when you talk
$work (like always). We will have both, some from management and some
engineers (including me) joining the call. If you have any Infra or CPE
questions, we would love to talk and answer (what we do, why we do and what
we are going to do are just a few examples). When we are out of questions,
expect it to look like a general social hour.
If you don't know what Fedora Social hour is, check
https://discussion.fedoraproject.org/t/join-us-for-fedora-social-hour-eve...
Looking forward to seeing a lot of you
2 years, 4 months
