From Fedora Project Wiki
(yet more changes throughout. lots of work on features and requirements -- but still skeletal!)
(Update Meeting times discussion.)
(43 intermediate revisions by 11 users not shown)
Line 1: Line 1:
'''CURRENTLY EDITING IN ETHERPAD. SEE #fedora-cloud on Freenode to coordinate.'''
{{header|cloud-sig}}
{{header|cloud-sig}}
Fedora Cloud Product Requirements Document.
<!-- The code for this page is kept at https://pagure.io/cloud-sig/blob/main/f/PRD.mw and should be edited and merged from there -->
= Document Purpose and Overview =
= Purpose and Demographic =
This is the [http://en.wikipedia.org/wiki/Product_requirements_document wikipedia Product Requirements Document] for the Fedora Cloud SIG. It:
The ''Fedora Cloud Edition'' allows users to work across multiple virtual environments at
* Provides a high-level market of the cloud computing market as it pertains to the Fedora Cloud SIG; this includes overviews of things which may not be within our actual scope/ability to accomplish at the current time.
scale by focusing engineering efforts on supplying a base disk images, rpms, and
* Provides deeper understanding of the types of users who could use Fedora for their cloud computing needs. This includes describing their main day-to-day tasks, common problems, and so on. The perspective here is not necessarily limited to system administrators, or developers, but a combination of many types of users and roles.
container-based tooling of various architectures for working in and around public and
* Ties common issues and needs of potential users and consumers of the Fedora Cloud product to high-level product needs, from a "functional" standpoint
private cloud environments. The ''Cloud Edition Working Group'' targets efforts towards the
* Provides solutions, in the form of "changes" or "features" which will provide the functionality described as needs for the potential users.
facilitation and improvement of continuous delivery by ensuring that Fedora project
= Release/Product Overview =
solutions support cloud native workflow without forcing users to understand all of the
Fedora Cloud provides a customizable base image and tools for developing scale out applications on public and private clouds, as well as two to four images pre-configured for what we expect to be the most popular scenarios/use cases for using Fedora for cloud computing.
environments in which they require enablement.
Public and private cloud adoption is taking off, and the requirements for an image OS differ significantly from the requirements for a desktop or server OS. In these environments, much or all of the instance lifecycle — from the creation of the image and addition of software or configuration specific to the instance, to the teardown of the image — will be automated. Systems are designed to scale out via many identical nodes rather than scale up with carefully-tended individual servers. Individual uptime (mean time between failure) is not as important as the ability to get a new instance running quickly (mean time to recovery).
 
With that in mind, we're tailoring a release specifically for cloud environments.  
= Product Objectives =
== Market Opportunity ==
== The Fedora Cloud Base Image ==
Public and private cloud adoption is happening rapidly, but the market is not yet mature and is relatively ripe for disruption even though some favorites have emerged as early leaders.
There are many requirements for building and deployment into the various options for
In the next two to three years, we expect to see a great deal of growth in adoption and still see a number of emerging players where no clear favorites have emerged (for instance, Google Compute Engine). Additionally, some platforms (Amazon Web Services) have matured to a point where a large number of companies are relying upon the technology for their full infrastructure. While this is not a widespread practice, AWS is seeing a great deal of adoption and will likely start eating into "traditional" workloads that currently live behind the firewall.
private and public clouds. The primary goal for the Cloud Edition is the Fedora Cloud Base
In short, there's an enormous opportunity for Fedora to become an instance-OS of choice if the project moves quickly, develops or adopts the right technologies, and succeeds in educating the market about its existence. A failure on any of those three points means that the Fedora Cloud product will have little chance in taking a significant portion of the new market or taking any of the existing market.  
Image. The Cloud Base image provides disk images for all of the environments that can be tested
=== Major Release Themes ===
and confirmed to be functional. It is foundational to additional configurations and
Cloud computing in general is the transition of computing power from individual hand-tended resources to a ubiquitous utility. Fedora fits in at several levels, from the infrastructure service software we include (like OpenStack and Eucalyptus) to end-user tools.
initiatives that require an image-based deployment model.
The Fedora Cloud image fits into middle of this, providing a guest OS image to run on Infrastructure as a Service systems, on which platform and application services can be deployed. We targets use cases which fit the "cattle" side of the "pets vs. cattle" metaphor for computing.
 
=== Secondary Objectives ===
== Adaptations for Hyperscaler Use Cases ==
Aside from adoption and development of applications on top of the Fedora Cloud images, we have a few secondary goals that will be helped by wider adoption:
Some use cases may be considered as antithetical to the goals of other edition deployment
* More testing of Fedora images with additional bug reports.
models, but have a strong use case to be included by default in hyperscalers. The use of
* Better feedback about how the product should improve. This is separate from "bug reports" in that we hope to engage the audience and receive detailed feedback about use cases, desired features, developing trends in cloud management, etc.
cloud-native components is continually evolving and highly opinionated, so there is added
* Patches and contributions that will help improve the product, and Fedora in general. As we are increasingly successful, more users will take an interest in helping to develop our product.
benefit to including these curated images for use in the exploration of new technologies
== Target Market / Audience ==
and scientific reproducibility.
Developers creating scale out applications on top of public and private clouds, and organizations and users running those applications. FIXME (this could use another sentence? or if you think it is both beautiful and sufficient, feel free to just delete this FIXME)
 
== Delivery Mechanisms ==
At the 2020 Power Management and Scheduling in the Linux Kernel summit (OSPM)[1], Andrea
Cloud images images must be easy to consume as part of a pulbic or private cloud. Because we target these environments, we won't be worrying about physical media at all. The cloud images also won't be "installed" in the same manner that users are accustomed to with desktop or server images. The cloud image will simply boot in its target environment ready to run, or for further customization and configuration via a boostrapping service.
Righi and Rafael Wysocki discussed the use of hibernation on cloud-based systems and
=== Where to obtain ===
reviewed work that they have done in support of the program. Jonathan Corbet points out
Users will be able to obtain the images for public clouds via download ''or'' via the usual marketplace for those images. For instance, we publish Amazon AMIs on Amazon directly. Users are able to launch new instances with Fedora without having to obtain the images directly from the Fedora Project and then upload to Amazon.
that "[t]he value there is to be able to pause a workload to save money. For example,
Users will be able to download appropriate images for Apache CloudStack, Eucalyptus, OpenStack, OpenNebula, and other IaaS platforms.
Amazon's ''spot instances'' run at low priority when there are spare resources available;
=== Delivery Format ===
they can be shut down with ten minutes notice at any time."  With support from the Cloud
Images will be delivered as AMIs on Amazon EC2, and as downloadable images in qcow2 and raw.xz formats. We may add other public cloud images and other downloadable formats to meet demand or anticipated need.
Edition team, the agents and kernel support can be maintained consistently and
=== Updates ===
reliably.
Fedora Cloud images can be updated using yum as normal. We also intend to produce periodic respun images with security updates, once the infrastructure is in place to support that.
 
=== Image Creation Toolkit ===
There are a number of example use cases to explore in both traditional and non-traditional
We will also maintain a set of tools that can be used to generate, modify, and configure Fedora instances for use with public and private clouds. Initial efforts will focus on creating official images in Fedora's build system. This effort is in parallel to that and does not block the main release. The Fedora Cloud SIG is also interested in a curated library of image templates.... FIXME BLAH BLAH BLAH
ways and some of them are included in the next section. This use cases section is intended
== Measuring Success ==
to be updated as time goes on to identify specific initiatives and configurations that the
Currently, Fedora is not a widely used option for instances on public and private clouds. We know there's some usage, but it's not one of the top three or four OSes on Amazon or (likely) for private clouds.
Cloud Edition can support.
Success looks like:
 
* Increase in adoption.
== Example Use Cases ==
* Third party support / targeting of Fedora Cloud as a platform.
=== An Example: Base image for use with Cloud IDE ===
* Increased contribution and participation in the Fedora Cloud WG and Fedora Project in general.
The use of Fedora as a foundation for IDE environments such as the Amazon ''Cloud9'' IDE
= User Profiles, Goals, and Primary Use Cases =
requires curation and support. When it is not properly prepared, it cannot be included as
== User Profiles ==
a part of the product offerings available to users who might wish to use them. A curated
FIXME: -- integrate this list, make pretty-sounding paragraph to introduce it. Move based-on to the credits section.
package group is beneficial, but insufficient for Amazon service teams to trust that there
Three Cloud User Roles (based on “Description and Application of Core Cloud User Roles” ACM CHIMIT 2011, December 4 2011) that describe the tasks of the people who interact with any cloud-based Information Technology system:
will be continued support. The Cloud Edition is consistent with other Fedora Editions, but
# Cloud Service Creator: Develop the technical and business aspects of a (simple or high-level) cloud service
includes some active modifications to ensure support for next-generation technologies that
# Cloud Service Provider: Provide all types of services (SPI, etc.) to a Service Consumer
would not be possible with systems intended to be more consistent with downstream
# Cloud Service Consumer: Consume all types of services (SPI) offered by a Service Provider
directives.
We will use a set of personas  to describe our target users and their respective needs. This document lists the personas in summary form, with detailed  explanations of each one available in a separate document. https://fedoraproject.org/wiki/Cloud_Personas
 
# AWS enthusiast and Early Adopter
=== An Example: Base Image optimized for use with cloud native Kubernetes services ===
#* Writes and maintains a number of AWS-deployed applications including staging and production.
Amongst the hyperscaler cloud infrastructures there are those services where a specialized
#* Works for a small start-up, primarily on his own. Automates as much as possible.
internal community is served. One for which the standard Fedora Editions does not include
#  DevOps Team Member
specialized support. Optimizing images for use with downstream platforms, i.e. not OKD or
#* Uses the cloud to do Ruby on Rails development utilizing virtual machines.
Red Hat OpenShift, for managing containerized workloads the cloud images can be for
#* Works as part of a DevOps team responsible for all aspects of a set of applications.
example, Kubernetes (k8s): Support for k8s is,in all cloud providers, an opinionated
#* Development, QA, and Production environments need to be identical.
configuration that fits specifically an immutable operations model.
# Web Developer
 
#* Concentrates on app development, not architecture, deployment, or operations.
=== An Example: (EDA) Electronic Design Automation ===
#* FIXME (second summary point)
EDA workloads typically target their support towards stable, downstream EL distributions
# Large-Environment Sysadmin
and are therefore not capable of moving as quickly as distributions like Fedora. With the
#* Interested in deploying self-service PaaS to lighten operational load
use of cloud-native technologies, it's clear that the design world is at last ready to
#* FIXME (second summary point)
engage agile processes for the development of system-on-chip (SoC) design. The electronic
# Data Scientist
design automation (EDA) industry is maneuvering itself into position that makes new
#* Works with large data sets and intends to
technologies critical to decreasing time to market. Almost all of the pieces to facilitate
#* FIXME (second summary point)
an SoC methodology are in place in terms of cloud-managed development tools. The industry
# HPC Scientist
open access model is an ideal dovetail to ensure that the Fedora Cloud Edition can be a
#* Moving from traditional batch and grid technology to the cloud
target for early development and adoption of advanced technology.
#* FIXME (second summary point)
 
== Primary Use Cases ==
For EDA, there is an expectation that a significant number of applications will run
FIXME: does this list cover all of our personas?
generally in the same operating space. Additionally as function specialization occurs, it
=== Web Application Deployment in a Public Cloud ===
will be beneficial to have an engineering specialization in tailoring these specialized
Modern web applications are deployed as a collection of interconnected services, including parts like web servers, application servers, databases, and caching layers. Fault tolerance is handled at the overall orchestration level rather than by individual instances Fedora Cloud can be the base of each of these parts, providing recent libraries, server software, and language toolchains. Each system will be managed using the public cloud's own management tools plus a configuration management system like Puppet, Chef, Salt, or Ansible.
operating systems to the requirements of software-defined architecture.
Code may be developed against different language stacks; if these are readily available to users, that's a win. In the real world, libraries and other code we don't include may also be required and we should make that as painless as possible.
 
FIXME: we mention Rails in our personas. Let's call that out specifically, as well as a few other major language stacks we know are priorities.,
== Focus on the familiarity of the users. ==
=== Web Application Deployment in Private Cloud ===
There are many people who have not advanced to the level of using container-based models
As above, but in a locally-deployed and managed private cloud system.
for their bespoke code or operations practices. We don't want to leave them
=== Web Application Deployment in Hybrid Cloud ===
behind. Furthermore, there are still established practices which can only support
As above, but rather than a single cloud provider, the application seamlessly takes advantage of resources in both a private and public cloud.
containerization in part. Supporting these transitional and hybrid models is the focus of
=== Hybrid Cloud as Staging Area ===
the Cloud Working Group.are looking at ways we can build support for next-generation
Application development and testing happens in-house on a private cloud, while production goes to a public cloud.
support models.
FIXME: MORE DETAILS
 
=== Big Data / Number-Crunching ===
Many users of applications software have decades of experience interacting with a base
Deploy scale-out application for data processing to public, private, or hybrid cloud.
operating system standard actions. They may not yet be able to move their practice to an
FIXME: more? Deetails????
immutable OS model or use projects that abstract away from decades of \*nix software
=== OpenShift Origin System ===
development models.
FIXME: make this tech-independent -- basis for PAAS. (OpenShift can be mentioned, but these should be problem-focused.)
 
OpenShift Origin is an open source platform-as-a-service system already included in Fedora.
== An established practice for investigating the best model for deployment and governance ==
A Fedora Cloud image focused on OpenShift would make it easy for users
In many cases, cloud providers may determine that their opinionated model is the best or
to run their own PaaS.
singularly valid model. This may be the result of focused groups or Product Managers who
=== Simple Deployment of code to from Development to Production ===
do not have a familiarity with the possiblities of incorporating open source into their
As a developer, I want to ensure that my code is easily deployable from my development environment to a QA environment and finally a production environment, without encountering compatibility issues or surprises from differences in the environment. A solution where an identical customized image or container is used in all three environments is ideal.
active process due to concerns of any sort. It is a function of the cloud working group as
=== Development as Part of a Team ===
curators of the edition to actively explore these management models and software decisions
As a member of a development team, I would like to develop in an environment where code can go through unit or functional testing, and be approved or accepted by other members of the team.
as a method to either determine the best of class open source interaction or to identify
Example: A feature described as “Continuous Integration platform” may be listed in the Features section, and the various tools available to implement  would be enumerated and described in the “non-functional requirements” section, and cross-coordinated with the server working group.
in a way that is acceptable to the greater Fedora community exactly why the current model
FIXME/note I (mattdm) don't think we're ready for this one -- it's more involved than the other things we are tackling. maybe after the first release?
is not handled in an [https://www.theopensourceway.org/ open source way].
=  Target IaaS environments =
 
The Fedora Cloud product can be used as a guest/VM/image under many IaaS services and providers. For projects that are not currently packaged within Fedora/EPEL, we may need to locate a kind person to ensure testing. These include:
Examples of opinionated models are the use of python 2.7 in Google's gcloud sdk or the practice
Open source IaaS systems:
of clobbering the systemd-acpid \`sleep.sh\` file in the Amazon Hibernation Agent. Simply
* OpenStack
put, these are problems for the Cloud Edition to resolve and to help work with the
* Eucalyptus
upstream teams responsible to make their applications functional in the context of the
* Apache Cloudstack
Fedora Distribution and downstream Enterprise Linux.
* OpenNebula
 
* oVirt (FIXME: should this be in our focus? it's more traditional enterprise virt than iaas)
As a part of the working group, this team builds, monitors and improves the upstream
Public clouds:
experiences complicated by closed or non-standard models to ensure that there is a path
* Amazon EC2
forward to remove the barriers that block open source success for the cloud communities to
* Google Compute Engine
which we are aligned.
* HP Cloud
 
* Rackspace
= Architectural Considerations =
* Digital Ocean
== Boot Support ==
* Linode
* Legacy Bios or ''Classic Boot''
= Features =
* UEFI
FIXME: this is documentation for us as PRD writers. Remove once the feature section is in better shape. :)
 
Features here address the primary and secondary use cases, product or secondary objectives,  market opportunities from above.
  The Boot support is dependent upon a number of other considedations. Neal Gompa's collaborative work with the Red Hat team has made our images ready for both without modification. Aarch64 is UEFI only.  
Features should provide functional requirements (“what it should do”) preferably in a narrative fashion - more of a story / solution description, rather than “package XYZ” - the features (the ways to meet a user's objectives?) each likely consist of more than one package/enhancement, and those packages should be detailed in the “Detailed requirements” section of this document, and each of those detailed requirements should refer back to which feature it supports.
 
== Feature #0 ==
== Processor Architecture Support ==
Feature description should be described in the line saying “Feature #1/2/etc.”.
Describe the feature in more detail, specifically addressing how it addresses user scenarios, primary or secondary use cases / objectives of the product.
Use a table to indicate the following items:
Priority (Must, Should, NTH)
Citation of use cases addressed
As work continues and specific detailed requirements are developed, reference the detailed requirements within this document helping to fulfill this feature. This helps to ensure awareness around “do we still have a feature if some of the detailed requirements are not fulfilled, and thus are not able to address the specific use case needs / user objectives.”
== Feature: Ready to run in Public and Private Clouds ==
The Fedora cloud image is ready to go out of the box in the public and private cloud environments we target. It includes cloud-init, the defacto standard for boot-time configuration for cloud instances, and the client provisioning tools for OpenStack Heat.
== Feature: Ready Access to Fedora Collection of Packages ==
SUPER FIXME
* normal packages
* language and application stacks to enable whatever you need... blah blah blah FIXME
* different versions of languages through Software Collections
* other technologies as they are developed and integrated
== Feature: Docker support ==
Docker is an easy to use interface for running application containers on Linux. Fedora is uniquely positioned to provide the best platform for Docker, since this container technology is not a security solution, but can be made reasonably secure when wrapped with SELinux. This includes adding libvirt support to the image, which is more heavyweight than many users of the image for other purposes will want, so we will produce a dedicated image specfically tailored for Docker.
== Feature: Big Data Tools ==
We will produce a specialized image with various tools for Big Data processing preloaded and preconfigured where possible. The exact composition of this image will be determined in collaboration with Fedora's Big Data SIG.
== Feature: Quick OpenShift Deployment ==
FIXME: ...
== Feature: Cloud -> Server ==
The Fedora Server product targets more traditional server roles, where systems have a more unique identity. The Fedora Cloud image supports this by providing a path to go from our base to a Fedora Server role, in effect taming one of your cloud computing "cattle" and making it into a "pet" traditional server — but running in a cloud environment.
== Future Features ==
The following areas are unlilel;y to be completely addressed in the upcoming iteration of Fedora Cloud, but we intend to work on them in the future.
=== Image Generation Tools ===
FIXME
=== Image or Image Template Library ===
FIXME
=== Higher-Level Cloud Tooling ===
FIXME
# Orchestration
# Performance / Scalability / Failover
# Logging / Auditing
# Monitoring / Notification
# Database requirements
= Requirements =
== Requirement #1: Reducing Image Footprint ==
FIXME Short description
=== Feature(s) Addressed ===
FIXME
=== Priority ===
Nice to Have. The current cloud image is reasonably sized when compared to our competitors. However, smaller footprint has several advantages. Fewer packages means fewer updates and a smaller target for security problems. It makes it faster to download and deploy images. And, reducing things our users don't really need gives more room to include things they do.
=== Specific Areas ===
This requirement has several areas where effort will yield meaningful results. Each has its own level of effort, stakeholders, and dependencies.
==== Cloud-Focused Base Kernel ====
* FIXME
==== Internationalization / Localization ===
*  FIXME NTH: Cloud Product base images should only includes en.us_US locale  since it is meant to be used as an deployment target to save space.  Other locales should be available through repositories.
The idea is to rely on langpacks rather than RPM wizardry.
==== Included Documentation ====
*  FIXME... same problem
==== Refactoring Cloud-Init= ===
* FIXME Dependency chain craziness, modules not necessarily right, etc.
== Requirement #2: Improved Docker Integration ==
FIXME -- particularly of interest, selinux support. also docker infrastructure, image building, dockerfiles, etc.
=== Feature(s) Addressed ===
FIXME
=== Priority ===
FIXME Must, should, NTH
=== Effort required ===
FIXME High, Medium, Low
=== Stakeholders / Owners ===
FIXME
=== Major Dependencies ===
FIXME
=== Testing ===
FIXME
=== Other Documentation ===
FIXME
== Requirement #3: Automatic Production and Upload of Images
FIXME: describe. qa also here? (taskotron?)
=== Feature(s) Addressed ===
FIXME
=== Priority ===
FIXME Must, should, NTH
=== Effort required ===
FIXME High, Medium, Low
=== Stakeholders / Owners ===
FIXME
=== Major Dependencies ===
FIXME
=== Testing ===
FIXME
=== Other Documentation ===
FIXME
== Requirement #4: Needs for Big Data Image
SUPER-FIXME: do we have anything here?
FIXME: short description
=== Feature(s) Addressed ===
FIXME
=== Priority ===
FIXME Must, should, NTH
=== Effort required ===
FIXME High, Medium, Low
=== Stakeholders / Owners ===
FIXME
=== Major Dependencies ===
FIXME
=== Testing ===
FIXME
=== Other Documentation ===
FIXME
== Requirement #5: Software Stacks for Various Languages
FIXME: short description
FIXME: different versions, lifespan greater than one cycle, etc.
=== Feature(s) Addressed ===
FIXME
=== Priority ===
FIXME Must, should, NTH
=== Effort required ===
FIXME High, Medium, Low
=== Stakeholders / Owners ===
FIXME
=== Major Dependencies ===
FIXME
=== Testing ===
FIXME
=== Other Documentation ===
FIXME
== Requirement #6: Integration with Fedora Server Roles
FIXME: short description
=== Feature(s) Addressed ===
FIXME
=== Priority ===
FIXME Must, should, NTH
=== Effort required ===
FIXME High, Medium, Low
=== Stakeholders / Owners ===
FIXME
=== Major Dependencies ===
FIXME
=== Testing ===
FIXME
=== Other Documentation ===
FIXME
== Requirement #7:  Tools for User Image Creation
FIXME: short description
FIXME: include either a) image library or b) library of image recipies
FIXME: docker images included here?
=== Feature(s) Addressed ===
FIXME
=== Priority ===
FIXME Must, should, NTH
=== Effort required ===
FIXME High, Medium, Low
=== Stakeholders / Owners ===
FIXME
=== Major Dependencies ===
FIXME
=== Testing ===
FIXME
=== Other Documentation ===
FIXME
== Requirement #8: Updated Web Site for Obtaining Cloud Images
FIXME: short description
FIXME: this is needed because we are increasing complexity!
=== Feature(s) Addressed ===
FIXME
=== Priority ===
FIXME Must, should, NTH
=== Effort required ===
FIXME High, Medium, Low
=== Stakeholders / Owners ===
FIXME
=== Major Dependencies ===
FIXME
=== Testing ===
FIXME
=== Other Documentation ===
FIXME
== Documentation ==
FIXME
=== Fedora Project Documentation ===
FIXME
=== Open Source Projects documentation ===
Ensuring that Fedora is well-represented, up-to-date in other open source project documentation...
== Release Criteria ==
FIXME -- should we punt on this for now?
= Technical requirements =
== Maintainability ==
== Support Requirements ==
=== Architectures Supported ===
* x86
* x86_64
* x86_64
* at some point: ARM (which variants ?)
* aarch64
=== Supported (platforms?) ===
 
Virtualization types? Container types?
= Participants =
== Security ==
Currently the following people are involved in the Cloud Working group.
FIXME -- also punt?
 
= About this Document =
* [https://fedoraproject.org/wiki/User:Davdunc David Duncan]
This PRD (Product Requirements Document) is an evolving document, created by the Fedora Cloud SIG Working Group as part of the process for designing the Fedora Cloud product. The framework for the PRD itself is currently in a draft state.
 
This document will evolve over time as the purpose of the SIG continues to be determined as the working group process gets under way and initial products start to get produced.
* [https://fedoraproject.org/wiki/User:Dustymabe Dusty Mabe]
== Authors ==
 
Contributors to this document include:
* [https://fedoraproject.org/wiki/User:Mhayden Major Hayden]
* [[User:rbergero|Robyn Bergeron]]
 
* [[User:mattdm|Matthew Miller]]
* [https://fedoraproject.org/wiki/User:Ngompa Neal Gompa]
* [[User:skottler|Sam Kottler]]
 
* [[User:Hguemar| Haïkel Guémar]]
* [https://fedoraproject.org/wiki/User:Dcavalca Davida Cavalca]
Some aspects of Fedora Cloud personas are based on [https://docs.google.com/document/d/16rkiXWxxgzGT47_Wc6hzIPzO2-s2JWAPEKD0gP2mt7E OpenStack personas] (licensed under CC-By 3.0).
 
== Reviewers & Contributors ==
* [https://fedoraproject.org/wiki/User:Salimma Michel Salim]
The following people have contributed to the development of this document, through feedback on IRC, mailing lists, and other points of contact.
 
* [[User:mattdm|Matthew Miller]]
* [https://fedoraproject.org/wiki/User:Chrismurphy Chris Murphy]
==  Community Information ==
 
The Fedora Cloud SIG is one of many teams within the Fedora Project.
* [https://blog.centos.org/2022/03/new-centos-director-amy-marrich/ Amy Marrich]
The Cloud SIG mailing list is located [https://admin.fedoraproject.org/mailman/listinfo/cloud here.]
 
Minutes and logs from IRC meetings related to the development of this document should be listed here as the document evolves.
* [https://fedoramagazine.org/joe-doss-how-do-you-fedora/ Joe Doss]
== Approval History ==
 
Over time, it is expected that this document will undergo various rounds of review, approval, and editing; in the future, it may be rewritten for different releases of Fedora.
Many others have participated in the past and the projects a whole was
While one can review the history of a wiki document (by clicking the "history" tab), it is useful to provide explicit indicators of any major format changes, approvals, or indications of it being in a “final” state, in a list that can allow someone to quickly see that all of the prescribed layers of approval have occured.  
founded by the current (2022) [https://docs.fedoraproject.org/en-US/council/fpl/ FPL], [https://fedoraproject.org/wiki/User:Mattdm Matthew Miller]. Matthew has been integral in
* January  8, 2014: Collaborative hackfest day.
working on the scope and practices followed by the Cloud Working Group for many years.
* October 28, 2013: [http://fedoraproject.org/w/index.php?title=Cloud_PRD&oldid=358260 Initial Draft of template.]
 
* FutureDate: Approval by SomeGroup; link to any pertinent mail announcement and/or meeting minutes
 
==Tracking of Progress==
= Project Status =
This document contains numerous descriptions of use cases, descriptions of feature sets to address the use cases, and the requirements to enable those features. Numerous Fedora self-contained and systemwide changess (in addition to updates to individual packages) may combine to address those use cases and feature sets. Thus, as a single release, or even series of releases, undergoes development, it is useful to easily track how an entire use case or feature set may be progressing.  
The Working group is '''ACTIVE'''
While Fedora uses the [[Changes/Policy | Changes Process]] to track changes in the distribution, those changes are typically described as details of changes to a specific package, or the introduction of a specific package, rather than as a piece of a larger feature set.
 
This document could possibly be used to do any or a number of the following things:
Currently the Cloud Working Group is focused on returning to status as
* Provide a secondary location where changes are tracked (which seems like a lot of overhead to me)
an [https://fedoraproject.org/wiki/Changes/RestoreCloudEdition Edition].  Edition status lapsed as a result of a number of
* Provide a location where overall Feature Progress is tracked, via periodic cross-checking against Change pages; this could be either in a standalone section, or simply attached to each Feature description.
changes. The first was a move to focus efforts related to cloud images
* Scope out  how features are expected to progress over a number of releases.
to include [https://projectatomic.io/ Project Atomic] as well as the standard cloud edition and
* None of these things.
then a complication occurred when Fedora Atomic was replaced by Fedora
FIXME -- add this When we more fully determine how to most efficiently track progress, the pointer to where that tracking is done, and/or the description of or process by which we do the tracking is formalized, should be documented in this section in lieu of what is currently written here.
CoreOS. The directives for these working groups is distinctly
== Document Conventions==
different and supports different goals related to downstream adoption
=== Definitions and Acronyms ===
and support.
* AWS: Amazon Web Services
 
* Amazon EC2: Amazon Elastic Compute Cloud, a popular public IaaS
== Meeting Times ==
* IaaS: Infrastructure as a Service
Bi-Weekly, every other Thursday. Currently we are supposed to be meeting at 15:00 UTC, but we have been meeting accidentally at 8:00 AM EDT daylight savings time. We are considering meeting on the 1st and 3rd of the month with a Video meeting on the 5th week of months that have a 5th week. Changing the meeting time would allow us to synchronize with the CentOS Cloud SIG for consistency.  
* PaaS: Platform as a Service
 
* SaaS: Software as a Service
----
* PRD: Product Requirements Document
=== Footnotes ===
* [[EPEL]]: Extra Packages for Enterprise Linux
 
* CI: Continuous Integration
[1] https://lwn.net/Articles/821158/n
* CD: Continuous Delivery or Continuous Deployment
* [[SoftwareCollections | SCL]]: Software Collections
* [[Category:SIGs|Special Interests Groups]]: teams in charge of some aspects of Fedora Project
* NTH: Nice-to-have
* BZ: [[Bugzilla]]
* GUI: Graphical User Interface
* CLI: Command Line Interface
* API: Application Programming Interface

Revision as of 14:53, 26 May 2022

The Fedora Cloud Special Interest Group

Purpose and Demographic

The Fedora Cloud Edition allows users to work across multiple virtual environments at scale by focusing engineering efforts on supplying a base disk images, rpms, and container-based tooling of various architectures for working in and around public and private cloud environments. The Cloud Edition Working Group targets efforts towards the facilitation and improvement of continuous delivery by ensuring that Fedora project solutions support cloud native workflow without forcing users to understand all of the environments in which they require enablement.

Product Objectives

The Fedora Cloud Base Image

There are many requirements for building and deployment into the various options for private and public clouds. The primary goal for the Cloud Edition is the Fedora Cloud Base Image. The Cloud Base image provides disk images for all of the environments that can be tested and confirmed to be functional. It is foundational to additional configurations and initiatives that require an image-based deployment model.

Adaptations for Hyperscaler Use Cases

Some use cases may be considered as antithetical to the goals of other edition deployment models, but have a strong use case to be included by default in hyperscalers. The use of cloud-native components is continually evolving and highly opinionated, so there is added benefit to including these curated images for use in the exploration of new technologies and scientific reproducibility.

At the 2020 Power Management and Scheduling in the Linux Kernel summit (OSPM)[1], Andrea Righi and Rafael Wysocki discussed the use of hibernation on cloud-based systems and reviewed work that they have done in support of the program. Jonathan Corbet points out that "[t]he value there is to be able to pause a workload to save money. For example, Amazon's spot instances run at low priority when there are spare resources available; they can be shut down with ten minutes notice at any time." With support from the Cloud Edition team, the agents and kernel support can be maintained consistently and reliably.

There are a number of example use cases to explore in both traditional and non-traditional ways and some of them are included in the next section. This use cases section is intended to be updated as time goes on to identify specific initiatives and configurations that the Cloud Edition can support.

Example Use Cases

An Example: Base image for use with Cloud IDE

The use of Fedora as a foundation for IDE environments such as the Amazon Cloud9 IDE requires curation and support. When it is not properly prepared, it cannot be included as a part of the product offerings available to users who might wish to use them. A curated package group is beneficial, but insufficient for Amazon service teams to trust that there will be continued support. The Cloud Edition is consistent with other Fedora Editions, but includes some active modifications to ensure support for next-generation technologies that would not be possible with systems intended to be more consistent with downstream directives.

An Example: Base Image optimized for use with cloud native Kubernetes services

Amongst the hyperscaler cloud infrastructures there are those services where a specialized internal community is served. One for which the standard Fedora Editions does not include specialized support. Optimizing images for use with downstream platforms, i.e. not OKD or Red Hat OpenShift, for managing containerized workloads the cloud images can be for example, Kubernetes (k8s): Support for k8s is,in all cloud providers, an opinionated configuration that fits specifically an immutable operations model.

An Example: (EDA) Electronic Design Automation

EDA workloads typically target their support towards stable, downstream EL distributions and are therefore not capable of moving as quickly as distributions like Fedora. With the use of cloud-native technologies, it's clear that the design world is at last ready to engage agile processes for the development of system-on-chip (SoC) design. The electronic design automation (EDA) industry is maneuvering itself into position that makes new technologies critical to decreasing time to market. Almost all of the pieces to facilitate an SoC methodology are in place in terms of cloud-managed development tools. The industry open access model is an ideal dovetail to ensure that the Fedora Cloud Edition can be a target for early development and adoption of advanced technology.

For EDA, there is an expectation that a significant number of applications will run generally in the same operating space. Additionally as function specialization occurs, it will be beneficial to have an engineering specialization in tailoring these specialized operating systems to the requirements of software-defined architecture.

Focus on the familiarity of the users.

There are many people who have not advanced to the level of using container-based models for their bespoke code or operations practices. We don't want to leave them behind. Furthermore, there are still established practices which can only support containerization in part. Supporting these transitional and hybrid models is the focus of the Cloud Working Group.are looking at ways we can build support for next-generation support models.

Many users of applications software have decades of experience interacting with a base operating system standard actions. They may not yet be able to move their practice to an immutable OS model or use projects that abstract away from decades of \*nix software development models.

An established practice for investigating the best model for deployment and governance

In many cases, cloud providers may determine that their opinionated model is the best or singularly valid model. This may be the result of focused groups or Product Managers who do not have a familiarity with the possiblities of incorporating open source into their active process due to concerns of any sort. It is a function of the cloud working group as curators of the edition to actively explore these management models and software decisions as a method to either determine the best of class open source interaction or to identify in a way that is acceptable to the greater Fedora community exactly why the current model is not handled in an open source way.

Examples of opinionated models are the use of python 2.7 in Google's gcloud sdk or the practice of clobbering the systemd-acpid `sleep.sh` file in the Amazon Hibernation Agent. Simply put, these are problems for the Cloud Edition to resolve and to help work with the upstream teams responsible to make their applications functional in the context of the Fedora Distribution and downstream Enterprise Linux.

As a part of the working group, this team builds, monitors and improves the upstream experiences complicated by closed or non-standard models to ensure that there is a path forward to remove the barriers that block open source success for the cloud communities to which we are aligned.

Architectural Considerations

Boot Support

  • Legacy Bios or Classic Boot
  • UEFI
 The Boot support is dependent upon a number of other considedations. Neal Gompa's collaborative work with the Red Hat team has made our images ready for both without modification. Aarch64 is UEFI only.

Processor Architecture Support

  • x86_64
  • aarch64

Participants

Currently the following people are involved in the Cloud Working group.

Many others have participated in the past and the projects a whole was founded by the current (2022) FPL, Matthew Miller. Matthew has been integral in working on the scope and practices followed by the Cloud Working Group for many years.


Project Status

The Working group is ACTIVE

Currently the Cloud Working Group is focused on returning to status as an Edition. Edition status lapsed as a result of a number of changes. The first was a move to focus efforts related to cloud images to include Project Atomic as well as the standard cloud edition and then a complication occurred when Fedora Atomic was replaced by Fedora CoreOS. The directives for these working groups is distinctly different and supports different goals related to downstream adoption and support.

Meeting Times

Bi-Weekly, every other Thursday. Currently we are supposed to be meeting at 15:00 UTC, but we have been meeting accidentally at 8:00 AM EDT daylight savings time. We are considering meeting on the 1st and 3rd of the month with a Video meeting on the 5th week of months that have a 5th week. Changing the meeting time would allow us to synchronize with the CentOS Cloud SIG for consistency.

Footnotes

[1] https://lwn.net/Articles/821158/n

Retrieved from "https://fedoraproject.org/w/index.php?title=Cloud/Cloud_PRD&oldid=645994"