I would like to present a Kubernetes Development SIG.
I initially thought of an "operator SIG" but I think a wider SIG about
programming components and services with Kubernetes APIs and internal
components made more sense (inspired by the "Programming Kubernetes" book).
I am using some of the fields/titles described in this document  as the
SIG: Kubernetes Development
A SIG for people interested in using, developing, extending kubernetes for
Fedora components and services.
Name: Leonardo Rossetti (lrossett)
Benefit to Fedora
Development Experience and Learning
A place to exchange and discuss kubernetes development design and patterns.
Extending kubernetes is not that straightforward so this SIG would be a
good place to learn more about it.
Kubernetes can be extended in the following areas:
* Kubectl Plugins
* Custom API Servers
* Custom Controllers / Operators
The Operator SDK  is the shining new framework when developing custom
kubernetes controllers nas has become a popular tool for packaging and
deploying applications in kubernetes.
Some Fedora services and components could leverage the usage of an operator
(as we are doing with MBBOX ) but other services could be deployed via
operators as well and even the mbbox operator could be split into smaller
The SIG could also be a place for sysadmins and ops engineers to discuss
the challenges, practices and tooling of monitoring, deploying and running
operators, api servers and other related kubernetes components in
 - https://fedoraproject.org/wiki/Changes/EmptyTemplate
 - https://github.com/fedora-infra/mbbox
 - https://github.com/operator-framework/operator-sdk
Senior Software Engineer,
Red Hat <https://www.redhat.com>
There is a new version of jbig2dec which the new version of ghostscript requires. Given how previous updates went I intend to try a side-tag now. If you think your package is affected then please follow the discussion at:
Also, if there are better ways to coordinate package builds across disjoint packager groups I'm open to suggestions. (jbig2dec does not version ABI properly, upstream wants it like that and has new checks which counteract ABI stability patches)
As many of you know, Fedora has an EOL policy that roughly tl;drs to:
"Fedora N goes to End of Life 4 weeks after Fedora N+2 Final Release (GA)."
The document also says:
> Branches for new packages in the SCM are not allowed for distribution X after
> the Fedora X+2 release and new builds are no longer allowed.
I've recently discovered that for 10+ years, this was interpreted as:
1. at release of Fedora N+2, new dist-git branches for N are no longer allowed
2. 4 weeks later, Fedora N is EOL
When I was told this, I found it very surprising. Mostly because we usually only
ever announce the actual EOL deadline and I've never seen an announcement that
says: "From now on, no new packages for Fedora N are possible."
But also because it doesn't really make sense to me. I can imagine a case when a
bug in Fedora N can be fixed by adding a new package (for example when we
accidentally introduce a new dependency) and I don't understand why this should
not be possible between Fedora N+2 release and Fedora N EOL. Understandably many
packagers might decide to WONTFIX at that point ("It's going EOL in couple weeks
anyway"), but if they choose to fix, we should allow them to do so.
Similarly, before Fedora N is EOL, it is considered supported, and a need to
introduce a new package to a supported Fedora version IMHO is valid, regardless
of the approaching EOL.
So, my question is: Should we fix the document to describe the long standing
practice more understandably, or should we change the practice to allow new
dist-git branches until the actual EOL?
Given the plans to make btrfs the default, I'll share some of my own
recent experiences, hopefully this can make it easier for the next person
One issue I've come across is that a btrfs filesystem can only be used
on hosts with the same page size as the host that created the filesystem
E.g. x86-64 kernels have a 4k default page size but powerpc64le kernels
have been compiled with the optional 64k page size. This impacts
If somebody creates some filesystems with the 4k parameter and then they
migrate them to the powerpc64le host, they won't mount
If they try to go the other way, the filesystems won't mount either
There are other non-btrfs issues related to the 64k page size, for
example, nouveau driver won't work either
To make things easier for btrfs, could it be worthwhile changing the
default page size from 64k back to 4k on default kernels for most
We've branched, so let's start the weekly blocker status email yayyyyy
1. libreport — abrt-server errors when processing zstd compressed core
dumps produced by systemd-246~rc1-1.fc33 — POST
ACTION: abrt maintainers to make a new release containing the fix
2. resteasy — FreeIPA deployment fails in current Rawhide due to
various issues with Java 11 — NEW
ACTION: resteasy maintainers to diagnose issue and fix or pass the
buck as appropriate
3. sddm — login stuck when changing users repeatedly (log out, log in
a different one) — NEW
ACTION: sddm maintainers to diagnose issue and fix or pass the buck as
4. selinux-policy — SELinux is preventing systemd-machine from
'create' accesses on the sock_file io.systemd.Machine. — POST
ACTION: selinux-policy maintainers to make a new release containing the fixes
5. tomcat — FreeIPA server deployment fails in
Fedora-Rawhide-20200714.n.0 — MODIFIED
ACTION: tomcat maintainers to investigate failed upgrade test
1. gnome-shell — Network manager started stuck when I tries connecting
to VPN (openconnect) after upgrade gnome-shell to 3.37.1-1.fc33
version — NEW
ACTION: gnome-shell maintainers to diagnose issue
2. systemd — systemd-resolved.service not work with DNS server placed
behind VPN (openconnect) — NEW
ACTION: systemd maintainers to diagnose issue
3. udisks2 — zram-setup(a)zram0.service: Failed to load configuration:
No such file or directory — NEW
ACTION: Someone! to figure out why udisks2-zram gets pulled in
1. libreport — https://bugzilla.redhat.com/show_bug.cgi?id=1860616 — POST
abrt-server errors when processing zstd compressed core dumps produced
abrt doesn't support core dumps compressed with zstd, which is now
used by systemd. Merged upstream PR uses libarchive to add support for
zstd (and other compression formats):
2. resteasy — https://bugzilla.redhat.com/show_bug.cgi?id=1866570 — NEW
FreeIPA deployment fails in current Rawhide due to various issues with Java 11
Deploying FreeIPA fails with a traceback in pki-tomcat. This appears
to be a dependency chain issue that (currently) ends at resteasy via
dogtag-pki. This may not be the last layer in the Java 11 onion.
3. sddm — https://bugzilla.redhat.com/show_bug.cgi?id=1861700 — NEW
login stuck when changing users repeatedly (log out, log in a different one)
This is now a blocker based on a recent approval-in-principle of a
release criterion related to logout and user switching. User processes
linger after logout which blocks logging in when another user has
logged in between the two sessions. Or when the second user logs back
in. Or when a single user logs in repeatedly. Using
KillUserProcesses=Yes helps the first problem, but raises on of its
own. It appears to be a race condition of some kind as the behavior is
not fully consistent.
4. selinux-policy — https://bugzilla.redhat.com/show_bug.cgi?id=1862686 — POST
SELinux is preventing systemd-machine from 'create' accesses on the
librvirt VMs and systemd-machined service fail with AVC denials.
Merged upstream PRs should fix the denials mentioned in this bug:
5. tomcat — https://bugzilla.redhat.com/show_bug.cgi?id=1857043 — MODIFIED
FreeIPA server deployment fails in Fedora-Rawhide-20200714.n.0 due to
pki-tomcat failing to run with "java.lang.ClassNotFoundException:
An upstream commit resulted in tomcat-coyote.jar missing packages. A
previous fix (FEDORA-2020-f897a68801) moved the goalposts.
tomcat-9.0.37-3 should fix this. Verification is blocked on BZ1866570,
but Adam's most recent upgrade test still fails with a
1. gnome-shell — https://bugzilla.redhat.com/show_bug.cgi?id=1830343 — NEW
Network manager started stuck when I tries connecting to VPN
(openconnect) after upgrade gnome-shell to 3.37.1-1.fc33 version
Connecting to an OpenConnect VPN using 2FA hangs after the second
factor is entered. The journal contains an array.toString() message
which may or may not be a red herring (it looks like a deprecation
2. systemd — https://bugzilla.redhat.com/show_bug.cgi?id=1863041 — NEW
systemd-resolved.service not work with DNS server placed behind VPN
When connected to an OpenConnect VPN, host name resolution fails.
Manually disabling the systemd-resolved service works around this
3. udisks2 — https://bugzilla.redhat.com/show_bug.cgi?id=1861463 — NEW
zram-setup(a)zram0.service: Failed to load configuration: No such file
Installation on armhfp and aarch64 single-board computers fails with
zram-setup errors. It appears to be a conflict betwen udisks2-zram and
zram-generator-defaults. Update FEDORA-2020-e143a283fb renamse the
service unit file to make its origin more obvious. Removing
udisks2-zram fixes the issue, but it's pulled in as a dependency of
something, so that needs to be identified.
He / Him / His
Senior Program Manager, Fedora & CentOS Stream