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
Show replies by date