I'd like to propose that we assemble some guidelines (and/or guiding principles) around what goes into the Fedora cloud image and how we assess making changes to the cloud image.
WHY IS THIS RELEVANT?
Cloud images are essentially highly-opinionated installations of Fedora meant for cloud instances. They contain a certain set of packages with a small amount of modifications and they're all packaged into a container (such as a qcow2 or raw image) that is fit for importing into cloud.
Any changes made to the image could improve or harm the user experience. Some users are sensitive to changes in disk or RAM usage, especially for smaller instances. Other users want more packages in the base installation to speed up ephemeral cloud operations (such as CI/CD, batch workloads, etc).
HOW DOES IT WORK NOW?
The Cloud SIG handles proposed cloud image changes during meetings. Although this is efficient for most modifications, decisions are subjective and are based on Cloud SIG members' experiences. The process doesn't lay out the considerations that someone should think about as they propose a change.
WHAT COULD WE DO?
I propose that we create a set of image guidelines that defines the goals of the cloud image contents so that anyone who wants to propose a change can understand how their potential change could improve or degrade the user experience. These guidelines would become the backbone of a review of a potential change and review process for the Cloud SIG.
The guidelines should contain questions that the Cloud SIG would like to see answered before making a decision. Possible questions could include:
* Does your change introduce additional dependencies?
* Does your change affect disk usage or RAM utilization?
* How does the change affect users who used the previous
version of the image and now use this new image?
* What is the anticipated user benefit of the change?
Results of previous decisions should be shown near the guidelines so people can understand what was proposed before and why it was accepted or not accepted. For example, we've had discussions around enabling firewalld at boot time in the cloud image and it would be nice to have a clear, concise message around why that is not done at this time. If something changes later that makes it worth adding a firewall at boot time, someone could say "oh, this is much easier now than it was before and here's why...".
It would make sense to keep this document version controlled in a wiki or documentation somewhere so that anyone could propose updates to the guidelines over time as Fedora evolves.
I'd be happy to lead this effort within the SIG and draft an initial set of guidelines if this sounds valuable to other people! 😉
Thanks for reading this far!
I have updated the PRD and I would like to request additions comments
and improvements to this first draft.
My first pass can be edited or modified in the cloud-sig fork at
Fedora Cloud Working Group <2022-05-24 Tue>
1 Purpose and Demographic
The /Fedora Cloud Edition/ allows users to work across multiple
virtual environments at scale by focusing engineering efforts on
supplying a base disk images, rpms, and container-based tooling of
various architectures for working in and around public and private
cloud environments. The /Cloud Edition Working Group/ targets efforts
towards the facilitation and improvement of continuous delivery by
ensuring that Fedora project solutions support cloud native workflow
without forcing users to understand all of the environments in which
they require enablement.
2 Product Objectives
2.1 The Fedora Cloud Base Image
There are many requirements for building and deployment into the
various options for private and public clouds. The primary goal for
the Cloud Edition is the Fedora Cloud Base Image. The Cloud Base image
provides disk images for all of the environments that can be tested
and confirmed to be functional. It is foundational to additional
configurations and initiatives that require an image-based deployment
2.2 Adaptations for Hyperscaler Use Cases
Some use cases may be considered as antithetical to the goals of other
edition deployment models, but have a strong use case to be included
by default in hyperscalers. The use of cloud-native components is
continually evolving and highly opinionated, so there is added benefit
to including these curated images for use in the exploration of new
technologies and scientific reproducibility.
At the 2020 Power Management and Scheduling in the Linux Kernel summit
(OSPM), Andrea Righi and Rafael Wysocki discussed the use of
hibernation on cloud-based systems and reviewed work that they have
done in support of the program. Jonathan Corbet points out that "[t]he
value there is to be able to pause a workload to save money. For
example, Amazon's /spot instances/ run at low priority when there are
spare resources available; they can be shut down with ten minutes
notice at any time." With support from the Cloud Edition team, the
agents and kernel support can be maintained consistently and reliably.
There are a number of example use cases to explore in both traditional
and non-traditional ways and some of them are included in the next
section. This use cases section is intended to be updated as time goes
on to identify specific initiatives and configurations that the Cloud
Edition can support.
2.3 Example Use Cases
2.3.1 An Example: Base image for use with Cloud IDE
The use of Fedora as a foundation for IDE environments such as the
Amazon /Cloud9/ IDE requires curation and support. When it is not
properly prepared, it cannot be included as a part of the product
offerings available to users who might wish to use them. A curated
package group is beneficial, but insufficient for Amazon service teams
to trust that there will be continued support. The Cloud Edition is
consistent with other Fedora Editions, but includes some active
modifications to ensure support for next-generation technologies that
would not be possible with systems intended to be more consistent with
2.3.2 An Example: Base Image optimized for use with cloud native Kubernetes services
Amongst the hyperscaler cloud infrastructures there are those services
where a specialized internal community is served. One for which the
standard Fedora Editions does not include specialized
support. Optimizing images for use with downstream platforms, i.e. not
OKD or Red Hat OpenShift, for managing containerized workloads the
cloud images can be for example, Kubernetes (k8s): Support for k8s
is,in all cloud providers, an opinionated configuration that fits
specifically an immutable operations model.
2.3.3 An Example: (EDA) Electronic Design Automation
EDA workloads typically target their support towards stable,
downstream EL distributions and are therefore not capable of moving as
quickly as distributions like Fedora. With the use of cloud-native
technologies, it's clear that the design world is at last ready to
engage agile processes for the development of system-on-chip (SoC)
design. The electronic design automation (EDA) industry is maneuvering
itself into position that makes new technologies critical to
decreasing time to market. Almost all of the pieces to facilitate an
SoC methodology are in place in terms of cloud-managed development
tools. The industry open access model is an ideal dovetail to ensure
that the Fedora Cloud Edition can be a target for early development
and adoption of advanced technology.
For EDA, there is an expectation that a significant number of
applications will run generally in the same operating
space. Additionally as function specialization occurs, it will be
beneficial to have an engineering specialization in tailoring these
specialized operating systems to the requirements of software-defined
2.4 Focus on the familiarity of the users.
There are many people who have not advanced to the level of using
container-based models for their bespoke code or operations
practices. We don't want to leave them behind. Furthermore, there are
still established practices which can only support containerization in
part. Supporting these transitional and hybrid models is the focus of
the Cloud Working Group.are looking at ways we can build support for
next-generation support models.
Many users of applications software have decades of experience
interacting with a base operating system standard actions. They may
not yet be able to move their practice to an immutable OS model or use
projects that abstract away from decades of *nix software development
2.5 An established practice for investigating the best model for deployment and governance
In many cases, cloud providers may determine that their opinionated
model is the best or singularly valid model. This may be the result of
focused groups or Product Managers who do not have a familiarity with
the possiblities of incorporating open source into their active
process due to concerns of any sort. It is a function of the cloud
working group as curators of the edition to actively explore these
management models and software decisions as a method to either
determine the best of class open source interaction or to identify in
a way that is acceptable to the greater Fedora community exactly why
the current model is not handled in an [open source way].
Examples of opinionated models are the use of python 2.7 in Google's
gcloud sdk or the practice of clobbering the systemd-acpid `sleep.sh`
file in the Amazon Hibernation Agent. Simply put, these are problems
for the Cloud Edition to resolve and to help work with the upstream
teams responsible to make their applications functional in the context
of the Fedora Distribution and downstream Enterprise Linux.
As a part of the working group, this team builds, monitors and
improves the upstream experiences complicated by closed or
non-standard models to ensure that there is a path forward to remove
the barriers that block open source success for the cloud communities
to which we are aligned.
[open source way] <https://www.theopensourceway.org/>
Currently the following people are involved in the Cloud Working
- [David Duncan]
- [Dusty Mabe]
- [Major Hayden]
- [Neal Gompa]
- [Davida Cavalca]
- [Michel Salim]
- [Amy Marrich]
- [Joe Doss]
Many others have participated in the past and the projects a whole was
founded by the current (2022) [FPL], [Matthew Miller]. Matthew has
been integral in working on the scope and practices followed by the
Cloud Working Group for many years.
[David Duncan] <https://fedoraproject.org/wiki/User:Davdunc>
[Dusty Mabe] <https://fedoraproject.org/wiki/User:Dustymabe>
[Major Hayden] <https://fedoraproject.org/wiki/User:Mhayden>
[Neal Gompa] <https://fedoraproject.org/wiki/User:Ngompa>
[Davida Cavalca] <https://fedoraproject.org/wiki/User:Dcavalca>
[Michel Salim] <https://fedoraproject.org/wiki/User:Salimma>
[Joe Doss] <https://fedoramagazine.org/joe-doss-how-do-you-fedora/>
[Matthew Miller] <https://fedoraproject.org/wiki/User:Mattdm>
4 Project Status
The Working group is *ACTIVE*
Currently the Cloud Working Group is focused on returning to status as
an [Edition]. Edition status lapsed as a result of a number of
changes. The first was a move to focus efforts related to cloud images
to include [Project Atomic] as well as the standard cloud edition and
then a complication occurred when Fedora Atomic was replaced by Fedora
CoreOS. The directives for these working groups is distinctly
different and supports different goals related to downstream adoption
[Project Atomic] <https://projectatomic.io/>
4.1 Meeting Times
Bi-Weekly, every other Thursday at 14:00 UTC
David Duncan | He/Him
Partner Solutions Architect, Linux
You are kindly invited to the meeting:
Fedora Cloud Workgroup on 2022-05-26 from 15:00:00 to 16:00:00 UTC
The meeting will be about:
Standing meeting for the Fedora Cloud Workgroup
Hi everyone. We have to cancel the cloud-sig meeting today. I am sorry about that.
I will update the calendar so that we don’t coincide with the CentOS-Cloud meeting from now on as well.
David Duncan, Partner Solutions Architect
Amazon Web Services
You are kindly invited to the meeting:
Fedora Cloud Workgroup on 2022-05-12 from 15:00:00 to 16:00:00 UTC
The meeting will be about:
Standing meeting for the Fedora Cloud Workgroup
I have two updates for azure-cli 2.36.0 pending. The Fedora 35 update is on its way to stable, but I was looking for testers for the Fedora 36 update.
I usually test an installation of the old packages and then an upgrade to the new packages to ensure I didn't miss any dependencies. Then I run an `az login` followed by some other commands to list resource groups, such as `az group list`. If you use Azure often, I'm sure you have plenty of other fun commands to try. 😉
Thanks in advance for any help you can provide!
Hey folks! Please see attached. Due to some late-breaking blockers and
fixes, we're now up to RC5 for F36 Final. Go/no-go is tomorrow. If
folks can help with testing, that'd be great.
Here's a quick summary of the changes between the RC composes:
RC1 -> RC2
gtk4-4.6.2-3.fc36 to fix #2071228
clevis-pin-tpm2-0.5.2-1.fc36 rust-tpm2-policy-0.6.0-1.fc36 to fix FTBFS
RC2 -> RC3
wpa_supplicant-2.10-4.fc36 to fix #2072070
tracker-miners-3.3.0-2.fc36 to fix #2079308
mutter-42.0-6.fc36 to fix #2081070
openssl-3.0.2-4.fc36 to fix #2069239
gzip-1.11-3.fc36 to fix #2073312
kernel-5.17.5-300.fc36 for #2080694
snapper-0.10.1-1.fc36 for FTBFS
selinux-policy-36.8-1.fc36 for #2065940
livecd-tools-30.0-1.fc36 for #2007045
xz-5.2.5-9.fc36 for #2080938
xdg-desktop-portal-1.12.4-1.fc36 for #2060990
sssd-2.7.0-1.fc36 for #2077856
gr-osmosdr-0.2.3-21.20210217gita100eb02.fc36 to fix FTBFS
RC3 -> RC4
firefox-100.0-2.fc36 for #2081488
RC4 -> RC5
sushi-41.2-1.fc36 for #2067969
gnome-photos-42.0-2.fc36 for #2079344 #2081291
aws-2020-7.fc36 matreshka-20.1-10.fc36 templates_parser-11.8.0-30.fc36 for FTBFS
So, RC3 had quite a lot of change in it. RC4 and RC5 are much more
limited. So we can count most tests from RC3 or later as being valid
for RC5; tests of Firefox, Nautilus and GNOME Photos should be re-
I have transferred results from RC3 and RC4 to RC5 in the matrix where
appropriate, leaving out things that are considered 'sanity tests'
(basic boot and install tests) which we try to run on every compose to
rule out some kind of cosmic bit-flip unexpectedly breaking an image.
So any spaces left on Basic/Beta/Final tests are ones we should try to
Special note on the Active Directory tests: it looks like tflink and
sgallagh ran these on RC1, thanks a lot. Since we did get a new sssd
between then and RC5 it would be *nice* if we could run them again, but
if not we can probably run with the RC1 results in the end.
Thanks again everyone!
IRC: adamw | Twitter: adamw_ha
👋🏻 Hey there,
Now that azure-cli is working well in Fedora 35/36/37, I've been approached to get it ready in EPEL9. Packaging the azure-cli package and some of the python-azure-* packages it needs doesn't look too difficult.
However, there are a lot of dependencies to consider. I maintain quite a few of these already, but there are many I do not maintain.
I'm starting to pile things into a COPR to get an idea of what will be involved.
Would azure-cli be useful to anyone in EPEL?
If so, would you want to help with dependencies? 😉 😉 😉
Thanks for reading this far!