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
_______________________________________________
cloud mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
