cloud June 2022

cloud@lists.fedoraproject.org

5 participants
5 discussions

Guidelines for changes to cloud images
by Major Hayden 28 Jul '22

28 Jul '22

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

3 3

[Fedocal] Reminder meeting : Fedora Cloud Workgroup
by dusty＠dustymabe.com 21 Jun '22

21 Jun '22

Dear all, You are kindly invited to the meeting: Fedora Cloud Workgroup on 2022-06-23 from 15:00:00 to 16:00:00 UTC At fedora-meeting-1(a)irc.libera.chat The meeting will be about: Standing meeting for the Fedora Cloud Workgroup Source: https://calendar.fedoraproject.org//meeting/1999/

1 0

[Fedocal] Reminder meeting : Fedora Cloud Workgroup
by dusty＠dustymabe.com 07 Jun '22

07 Jun '22

Dear all, You are kindly invited to the meeting: Fedora Cloud Workgroup on 2022-06-09 from 15:00:00 to 16:00:00 UTC At fedora-meeting-1(a)irc.libera.chat The meeting will be about: Standing meeting for the Fedora Cloud Workgroup Source: https://calendar.fedoraproject.org//meeting/1999/

1 0

Upcoming changes to Docs presentation
by Ben Cotton 02 Jun '22

02 Jun '22

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-sign… [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 0

Cloud SIG packager group?
by Major Hayden 01 Jun '22

01 Jun '22

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

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cloud June 2022