Guidelines for changes to cloud images

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