Guidelines for changes to cloud images
by Major Hayden
Howdy,
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!
--
Major Hayden
1Â year, 2Â months
Upcoming changes to Docs presentation
by Ben Cotton
Hi friends! On behalf of the Docs team, I'd like to share with your
our plans to reorganize how some documentation is presented to users.
You can read about it on the Community Blog[1]. The short version is
that we intend to replace the release-based focus with a focus on our
variants. Behind the scenes, content will be reused as much as
possible, but users will be presented with documentation focused on
how they get Fedora Linux: as Workstation, Server, etc. You can see
the proof of concept on Fedorapeople[2].
As part of this, we'd like your input and your help (perhaps even
designating someone in the group to be a liaison to the Docs team to
help us keep the content up-to-date). You can always reach us on the
#docs tag in Discussion[3] or in #docs:fedoraproject.org on Matrix
(#fedora-docs on Libera.chat). We're also holding two office hours
next week:
* Tuesday June 7, 1500 UTC fedora-meeting-1(a)libera.chat
* Thursday June 9 1900 UTC fedora-meeting-2(a)libera.chat
[1] https://communityblog.fedoraproject.org/fedora-docs-is-about-to-change-si...
[2] https://pboy.fedorapeople.org/fedora/
[3] https://discussion.fedoraproject.org/tag/docs
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1Â year, 3Â months
Cloud SIG packager group?
by Major Hayden
Hey there,
I can't remember exactly when, but the idea came up around creating a
packaging group for the Cloud SIG. The idea sounds like a good one.
A packaging group allows the SIG to get packages updated more quickly
when a bug or CVE appears. Also, we could take a more unified approach
to how we handle different types of cloud-related packages, especially
around the growing list of cloud CLIs and SDKs.
It was also noted that adding a packaging group drastically increases
the amount of email we would receive from various tools, especially
Bugzilla. 😅
My main questions are:
1) Would a Cloud SIG packaging group make sense?
2) How do we handle the email floods?
3) If this idea sounds good, what steps do we need to do?
Thanks for reading this far!
--
Major Hayden
1Â year, 4Â months
