From Fedora Project Wiki
No edit summary
(→‎Product Objectives: Update the general statement)
 
(61 intermediate revisions by 11 users not shown)
Line 1: Line 1:
{{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 =
== What this document describes ==
The ''Cloud Edition Working Group'' targets efforts towards the
This is the [http://en.wikipedia.org/wiki/Product_requirements_document wikipedia Product Requirements Document] for the Fedora Cloud SIG. It:
facilitation and improvement of continuous delivery by ensuring that Fedora project
* 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.
solutions support cloud native workflow without forcing users to understand all of the
* 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, etc. The perspective here is not necessarily limited to system administrators, or developers, but a combination of many types of users and roles.
environments in which they require enablement.
* Ties common issues and needs of potential users/consumers of the Fedora Cloud product to high-level product needs, from a "functional" standpoint
 
* Provides solutions, in the form of "changes" or "features," which will provide the functionality described as needs for the potential users.
= Product Objectives =
= Release/Product Overview =
The ''Fedora Cloud Edition'' allows users to work across multiple virtual environments at
Fedora Cloud provides a customizable base image and tools for developing scale out applications on public and private clouds, as well as a small number of images pre-configured for specific uses.
scale by focusing engineering efforts on supplying a base disk images, rpms, and
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).
container-based tooling of various architectures for working in and around public and
With that in mind, we're tailoring a release specifically for cloud environments.  
private cloud environments.
== Market Opportunity ==
 
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.
== The Fedora Cloud Base Image ==
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.
There are many requirements for building and deployment into the various options for
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.  
private and public clouds. The primary goal for the Cloud Edition is the Fedora Cloud Base
== Product Objectives ==
Image. The Cloud Base image provides disk images for all of the environments that can be tested
The Fedora Cloud product consists of an image to be used to run one or more instances in a public cloud, and a set of tools for creating and modifying images. We will also provide two to four additional images that are pre-configured for what we expect to be the most popular scenarios/use cases for using Fedora in public or private cloud.  
and confirmed to be functional. It is foundational to additional configurations and
=== Major Release Themes ===
initiatives that require an image-based deployment model.
Cloud computing in general is the transition of computing power from individual hand-tended resources to a ubiquitous utility. Fedora fits into this at several levels, from the infrastructure service software we include (like OpenStack and Eucalyptus) to end-user tools.
 
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.
== Adaptations for Hyperscaler Use Cases ==
=== Secondary Objectives ===
Some use cases may be considered as antithetical to the goals of other edition deployment
Aside from adoption and development of applications on top of the Fedora Cloud images, we have a few secondary goals that should be helped by wider adoption:
models, but have a strong use case to be included by default in hyperscalers. The use of
* More testing of Fedora images with additional bug reports.
cloud-native components is continually evolving and highly opinionated, so there is added
* 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.
benefit to including these curated images for use in the exploration of new technologies
* Patches and contributions that will help improve the product, and Fedora in general. Assuming we're successful, some users should take an interest in helping to develop our product.
and scientific reproducibility.
== Target Market / Audience ==
 
Developers creating scale out applications on top of public and private clouds, and organizations and users running those applications.
At the 2020 Power Management and Scheduling in the Linux Kernel summit (OSPM)[1], Andrea
== Delivery Mechanisms ==
Righi and Rafael Wysocki discussed the use of hibernation on cloud-based systems and
We need to ensure that images are as easy to consume as possible.  
reviewed work that they have done in support of the program. Jonathan Corbet points out
Since Fedora Cloud images are meant to be consumed as part of a public or private cloud, 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 and/or for further customization/configuration.
that "[t]he value there is to be able to pause a workload to save money. For example,
=== Where to obtain ===
Amazon's ''spot instances'' run at low priority when there are spare resources available;
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.
they can be shut down with ten minutes notice at any time."  With support from the Cloud
Users will be able to download appropriate images for Apache CloudStack, Eucalyptus, OpenStack, and other IaaS platforms.
Edition team, the agents and kernel support can be maintained consistently and
=== Delivery Format ===
reliably.
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.
 
=== 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.
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. We should be able to measure this semi-accurately on Amazon (at least) as the publisher.
== 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
Still working out some logic on this section. But forging ahead with what I have for the moment.
a part of the product offerings available to users who might wish to use them. A curated
Goal of this section is to provide insight into either or both of:
package group is beneficial, but insufficient for Amazon service teams to trust that there
* Primary Use Cases: What are the situations / environments in which we expect a Fedora Cloud Product to be used
will be continued support. The Cloud Edition is consistent with other Fedora Editions, but
* User Profiles and Goals: This is more like “personas” work, or could be done as “user stories” (more along the lines of agile, see http://en.wikipedia.org/wiki/User_story )
includes some active modifications to ensure support for next-generation technologies that
... and then ensure that for each type of user or use case, we have features/changes that make the Fedora Cloud product useful.
would not be possible with systems intended to be more consistent with downstream
== User Profiles ==
directives.
Based on [https://docs.google.com/document/d/16rkiXWxxgzGT47_Wc6hzIPzO2-s2JWAPEKD0gP2mt7E OpenStack personas] (licensed under CC-By 3.0).
 
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:
=== An Example: Base Image optimized for use with cloud native Kubernetes services ===
# Cloud Service Creator: Develop the technical and business aspects of a (simple or high-level) cloud service
Amongst the hyperscaler cloud infrastructures there are those services where a specialized
# Cloud Service Provider: Provide all types of services (SPI, etc.) to a Service Consumer
internal community is served. One for which the standard Fedora Editions does not include
# Cloud Service Consumer: Consume all types of services (SPI) offered by a Service Provider
specialized support. Optimizing images for use with downstream platforms, i.e. not OKD or
=== Persona #1: Alan the AWS enthusiast ===
Red Hat OpenShift, for managing containerized workloads the cloud images can be for
Alan was a very early AWS adopter. He writes and maintains a number of AWS-deployed applications, including staging and production, from the same data source. He needs to monitor his applications for cost, resource consumption, demand peaks and any crashes. He works for a small start-up. Puppet master.
example, Kubernetes (k8s): Support for k8s is,in all cloud providers, an opinionated
* Adoption curve: Innovator
configuration that fits specifically an immutable operations model.
* Skills: Experienced web developer & operations guy - not on his first cloud application architecture, mastery of continuous integration (CI) and continuous delivery (CD).
 
* Behavior patterns: Wants to concentrate on application development, not architecture. Change management - applying security updates to guest systems - takes a chunk of his time. He spends a little time every few months evaluating the cloud architecture to consider alternative components to increase price/performance.
=== An Example: (EDA) Electronic Design Automation ===
* Goals: To deliver excellent scalable web-deployed applications with a web interface and robust API for a mobile application front-end. To deliver incremental, tested updates to the applications on a regular basis.
EDA workloads typically target their support towards stable, downstream EL distributions
* Needs: Application lifecycle management, monitoring, to make his apps faster. Makes heavy use of cloud APIs and services to minimize work he has to do setting up his own services.
and are therefore not capable of moving as quickly as distributions like Fedora. With the
* Main Tasks: writing and deploying code. Anything that requires a significant distraction from that is a time sink, and Alan has little tolerance for mucking with infrastructure more than he has to.  
use of cloud-native technologies, it's clear that the design world is at last ready to
* Attitudes: Alan loves AWS. He's unlikely to consider an alternative public cloud due to dependencies on AWS services and the fact that migration would consume too many cycles that he doesn't have.
engage agile processes for the development of system-on-chip (SoC) design. The electronic
* Beliefs: Continuous deployment is king. Automate all the things. Do the hardest things often, until they’re easy. etc.
design automation (EDA) industry is maneuvering itself into position that makes new
* Motivations: getting the code running in production
technologies critical to decreasing time to market. Almost all of the pieces to facilitate
* Frustrations: poor command line tools,
an SoC methodology are in place in terms of cloud-managed development tools. The industry
* Environment: Macbook for development, AWS for development, testing, and production environments.
open access model is an ideal dovetail to ensure that the Fedora Cloud Edition can be a
* Interface Usage Tendencies:
target for early development and adoption of advanced technology.
** GUI: Medium
 
** CLI: Medium
For EDA, there is an expectation that a significant number of applications will run
** API: High
generally in the same operating space. Additionally as function specialization occurs, it
* Collaborates With: Alan is pretty much working alone. He may work with other folks in the start-up, but not on a daily or regular basis. His work flow is tooled specifically for his convenience.
will be beneficial to have an engineering specialization in tailoring these specialized
=== Persona #2: Erin the Rails devops team member ===
operating systems to the requirements of software-defined architecture.
Erin uses the cloud to do Ruby on Rails development utilizing virtual machines.
 
* Adoption curve: Early adopter
== Focus on the familiarity of the users. ==
* Skills: Familiar with Linux systems. Several years' programming experience, comfortable with Linux and other environments.
There are many people who have not advanced to the level of using container-based models
* Behavior patterns: Will choose from the range of available flavors of VMs to run. Will use OpenStack images to launch instances, also create and save her own.
for their bespoke code or operations practices. We don't want to leave them
* Goals: To set up and use cloud guests for her application with minimal effort. Erin is focussed on the application and regards the IaaS services as resources to be used with a minimum of administrative overhead. Would prefer if her language stack were just there and just worked in the cloud guests of her choice.
behind. Furthermore, there are still established practices which can only support
* Needs: Easy way to create cloud guests configured with the versions of Ruby and Rails used for her various projects.
containerization in part. Supporting these transitional and hybrid models is the focus of
* Main Tasks: Deploying and updating code in development, testing, and production environments. Maintains the guest images used as a base in all three.
the Cloud Working Group.are looking at ways we can build support for next-generation
* Attitudes: Hates it when things change just for change's sake. Wants the latest of the things her team needs, wants the rest
support models.
* Beliefs: The development, test, and production enviroments need to be identical.
 
* Motivations: provisionning environments quickly and easily
Many users of applications software have decades of experience interacting with a base
* Frustrations: lacking guest images preconfigured with her application framework
operating system standard actions. They may not yet be able to move their practice to an
* Workflow: Will mostly use the GUI and command line to set up and interact with OpenStack services, and will ensure that rolling out the application will be automated as much as possible. She will use the dashboard to monitor consumption of resources on an ongoing basis. Some else in her group has primary responsibility for managing the IaaS layer, but she can pitch in with a basic understanding if need be.
immutable OS model or use projects that abstract away from decades of \*nix software
* Environment: Linux development system. Primarily launches cloud instances via the OpenStack GUI. Part of a devops team which manages the a small OpenStack deployment for their own use.
development models.
* Interface Usage Tendencies:
 
** GUI: Medium-High
== An established practice for investigating the best model for deployment and governance ==
** CLI: Medium
In many cases, cloud providers may determine that their opinionated model is the best or
** API: Low
singularly valid model. This may be the result of focused groups or Product Managers who
* Collaborates With: Other members of her development and production operations team.
do not have a familiarity with the possiblities of incorporating open source into their
=== Persona #3: Walter the Web Developer ===
active process due to concerns of any sort. It is a function of the cloud working group as
Walter develops feature rich HTML5 applications using Symfony and Twitter Bootstrap, and a range of other web technologies. He has no real system administration skills, and develops on a single desktop computer or his MacBook. Walter wants the app to Just Work when he’s finished, and doesn’t really think a lot about caching, sharding, proxies, or making his app scalable. He works in a medium sized development shop which has people who take care of deployment and change management to the web applications he produces.
curators of the edition to actively explore these management models and software decisions
By-line: “Not a bug: Works for me”
as a method to either determine the best of class open source interaction or to identify
* Adoption curve: Early majority (Early adopter for web technologies)
in a way that is acceptable to the greater Fedora community exactly why the current model
* Skills: PHP, Ruby, Python, Javascript, CSS, multiple MVC frameworks, experienced Linux & MacOS X user (but not admin), comfortable setting up LAMP, github.
is not handled in an [https://www.theopensourceway.org/ open source way].
* Behavior patterns: Wants to concentrate on application development, not architecture. Spends most of his time in TextMate, and testing how app behaves and looks in VirtualBox.
 
* Goals: To deliver excellent web applications and robust RESTful API for mobile apps.
Examples of opinionated models are the use of python 2.7 in Google's gcloud sdk or the practice
* Needs: Up to date application development stack, good developer tools, someone to actually deploy his app.
of clobbering the systemd-acpid \`sleep.sh\` file in the Amazon Hibernation Agent. Simply
* Main Tasks:
put, these are problems for the Cloud Edition to resolve and to help work with the
* Attitudes: Walter would like to know more about the cloud but there’s so much to learn, he has no real idea where to start, and just keeping on top of new web development trends takes all his research time.
upstream teams responsible to make their applications functional in the context of the
* Beliefs: “This stuff should be easier to get a handle on”
Fedora Distribution and downstream Enterprise Linux.
* Environment: Macbook for development, a Linux desktop for test deployment, VirtualBox for testing on different browsers.
 
* Interface Usage Tendencies:
As a part of the working group, this team builds, monitors and improves the upstream
** GUI: High
experiences complicated by closed or non-standard models to ensure that there is a path
** CLI: Low
forward to remove the barriers that block open source success for the cloud communities to
** API: Low
which we are aligned.
* Collaborates With:
 
=== Persona #4: Martina the Senior Sysadmin ===
= Architectural Considerations =
Martina is a senior systems administrator at a large university. She has to manage more systems than she really has time for, and much of her time is interrupted by requests from grad students and other members of the university for resources. The IT department has some automated systems for deploying new sites with Drupal, Wordpress, MediaWiki or the like, but it needs to be done by hand.
== Boot Support ==
Martina's group has recently deployed an OpenStack environment, allowing some groups
* Legacy Bios or ''Classic Boot''
to provision virtual machines by themselves. This is some help, but is a level
* UEFI
too low to take care of most users' real needs. She's interested in taking this
 
one step further and providing a full Platform as a Service offering.
  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.  
By-line: "I could automate this, if I weren't so busy."
 
* Adoption curve: Early adopter
== Processor Architecture Support ==
* Skills: Shell scripting expert, hacks at Python, Perl, and just about anything else. Good at putting all the parts together.
* x86_64
* Behavior patterns: Would like to work on interesting emerging technologies that she believes will really help her employer and her users, but keeps getting interrupted by break/fix and user help requests.
* aarch64
* Goals: Provide a self-service application infrastructure for users.
 
* Needs: Robust deployment tools, simple automation stack, ability to rapidly provision large number of hetergenous systems at once, and then efficiently monitor and change them.
= Participants =
* Main Tasks: Provision new systems on both the public cloud and the private OpenStack cloud her company runs. Work with developers to deploy code as often as possible.
Currently the following people are involved in the Cloud Working group.
* Attitudes: -
 
* Beliefs: “Whenever a sysadmin has to interact with a user directly, something has gone wrong”
* [https://fedoraproject.org/wiki/User:Davdunc David Duncan]
* Environment: Fedora on her desktop, Android on a phone
 
* Interface Usage Tendencies:
* [https://fedoraproject.org/wiki/User:Dustymabe Dusty Mabe]
** UI: Low
 
** CLI: High
* [https://fedoraproject.org/wiki/User:Mhayden Major Hayden]
** API: Medium-Low
 
* Collaborates With: Developers, junior administrators, CTO, finance organization
* [https://fedoraproject.org/wiki/User:Ngompa Neal Gompa]
=== Persona #5: Susan the Scientist ===
 
Susan is a researcher at a major university. She works with large data sets and intends to
* [https://fedoraproject.org/wiki/User:Dcavalca Davida Cavalca]
process them with map-reduce. She plans to test this in her lab and then scale out to
 
local cloud resources and to spot instances in Amazon EC2. Unfortunately, her local
* [https://fedoraproject.org/wiki/User:Salimma Michel Salim]
Academic Computing department was recently merged into University Central Information
 
Systems and she doesn't get much support.
* [https://fedoraproject.org/wiki/User:Chrismurphy Chris Murphy]
By-line: "I can hack on the computing environment, but I'd rather work on the research problem."
 
* Adoption curve: Early adopter
* [https://blog.centos.org/2022/03/new-centos-director-amy-marrich/ Amy Marrich]
* Skills: Python, Fortran, Octave, R, learning Hadoop, Cassandra, and Pig.
 
* Behavior patterns: Most interested in results, but not afraid of tackling new technology to get there.
* [https://fedoramagazine.org/joe-doss-how-do-you-fedora/ Joe Doss]
* Goals: Crunch her data.
 
* Needs:
Many others have participated in the past and the projects a whole was
* Main Tasks: -
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
* Attitudes: -
working on the scope and practices followed by the Cloud Working Group for many years.
* Beliefs: -
 
* Environment: Fedora on her lab workstations, CentOS servers in the university data center (including an OpenStack deployment), uses public clouds like Rackspace, the HP cloud, or AWS spot instances to spin up many servers at once for a short period of time, a Mac laptop
 
* Interface Usage Tendencies:
= Project Status =
** GUI: Medium
The Working group is '''ACTIVE'''
** CLI: Medium
 
** API: Medium
Currently the Cloud Working Group is focused on returning to status as
* Collaborates With: -
an [https://fedoraproject.org/wiki/Changes/RestoreCloudEdition Edition].  Edition status lapsed as a result of a number of
=== Persona #5 (alternative) : Sarah the Data Scientist ===
changes. The first was a move to focus efforts related to cloud images
Sarah is a data scientist in a biotech startup. She works with large data sets and intends to
to include [https://projectatomic.io/ Project Atomic] as well as the standard cloud edition and
process them with map-reduce. She plans to test this in her office and then scale out to
then a complication occurred when Fedora Atomic was replaced by Fedora
local cloud resources and to spot instances in Amazon EC2
CoreOS. The directives for these working groups is distinctly
By-line: "Crunching a large set of data, get it done and done efficiently"
different and supports different goals related to downstream adoption
* Adoption curve: innovator
and support.
* Skills: Python, Scala, Octave, R, Hadoop, Cassandra, and Pig.
 
* Behavior patterns: Most interested in results, but not afraid of tackling new technology to get there.
== Meeting Times ==
* Goals: Process data quickly and efficiently, at the lowest cost possible. Since Sarah is potentially working with medical data, she cares about data strorage, retention policies, and ethical issues around her data - not just reliability and cost.
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.  
* Needs: -Reliable images with the latest improvements in her toolchain. Does not want to compile her own Hadoop, Pig, Mahout, etc.
 
* Main Tasks: collecting/crunching data, creating visualizations from data, managing data storage/retention.
----
* Attitudes: she cares about performance and is energy-conscious. Cares about security and the ethics of data management.
=== Footnotes ===
* Beliefs: -
 
* Environment: Fedora on her workstations, CentOS servers in the data center (including an OpenStack deployment),  uses public clouds like Rackspace, the HP cloud, or AWS spot instances  to spin up many servers at once for a short period of time, a Mac laptop
[1] https://lwn.net/Articles/821158/n
* Interface Usage Tendencies:
** GUI: Medium
** CLI: Medium
** API: Medium
* Collaborates With: -
=== Persona #6: Jody the HPC Scientist ===
Jody is a researcher at a major university. She previously used grids to solve meteorological simulations using
batch schedulers (SGE, Torque).
Since she needs to run many parallels simulations, she thinks about using cloud ressources for temporary infrastructure overflow.
By-line: "I need a bunch of machines to run my computational tasks, cloud or not."
* Adoption curve: Early majority
* Skills: Shell, Python, Fortran
* Behavior: Most interested in results, but not afraid of tackling new technology to get there.
* Goals: Run her computational tasks
* Needs: access to distributed filesystems (NFS, GlusterFS)
* Main Tasks: Designing experiments and running them
* Attitudes: She is not a computer nerd, but someone who likes to get things done
* Beliefs: -
* Environment: Fedora on her lab workstations, CentOS servers in the university data center (including an OpenStack deployment),  uses public clouds like Rackspace, the HP cloud, or AWS spot instances  to spin up many servers at once for a short period of time, a Mac laptop
* Interface Usage Tendencies:
** GUI: Medium
** CLI: Medium
** API: Medium
* Collaborates With: other scientists, few research engineers (sysadmin or developers)
== Primary Use Cases ==
=== Web Application Deployment in a Public Cloud ===
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.
=== Web Application Deployment in Private Cloud ===
As above, but in a locally-deployed and managed private cloud system.
=== Web Application Deployment in Hybrid Cloud ===
As above, but rather than a single cloud provider, the application
seamlessly takes advantage of resources in both a private and public
cloud.
=== Big Data / Number-Crunching ===
Deploy scale-out application for data processing to public, private, or hybrid cloud.
=== Docker Container Host ===
Docker is a technology for running applications inside a protected
container. These containers run under the host kernel, but otherwise
are self-contained. The Fedora Cloud image running in either a private
or public cloud can provide the host level, including basic docker
management tools plus tools for security and for access to storage.
Workflow may involve developing and testing Docker containers on
local system and pushing to cloud for production.
=== OpenShift Origin System ===
OpenShift Origin is an open source platform-as-a-service system already included in Fedora.
A Fedora Cloud image focused on OpenShift would make it easy for users
to run their own PaaS.
=== Simple Deployment of code to from dev to production ===
As a developer, I want to ensure that my code is easily deployable from my development environment to a production environment, without encountering issues of non-compatibility.
Example: A feature described as “Improved deployment of code to a cloud” might be fully described in the Features section, and as a result, Vagrant might be listed as a requirement in the non-functional requirements section, and cross-coordinated with the workstation working group. There are likely numerous other requirements as well.
=== Development as part of a team ===
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.
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.
=== Development using libraries not included in the distribution ===
As a developer, my toolchain includes libraries or dependencies on other packages using libraries not in the Fedora distribution, and I may be developing for distributions not limited to Fedora.
Example: A feature described as “Portable code” (REALLY POOR DESCRIPTION, sorry) may be listed in the Features section, and “Software Collections” might be listed as a requirement.
Note that this may have some cross-over with a possible additional story/use case, “Deployment of code using libraries not included in the distribution.”
=  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:
Open source IaaS systems:
* OpenStack
* Eucalyptus
* Apache Cloudstack
* OpenNebula
* oVirt
Public clouds:
* Amazon EC2
* Google Compute Engine
* HP Cloud
* Rackspace
* Digital Ocean
* Linode
= Features =
Features here address the primary and secondary use cases, product or secondary objectives,  market opportunities from above.
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 #1 ==
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 #2 ==
= Detailed Requirements =
Supporting packages / work required for the product itself to function to address the use cases above. Non-functional requirements (i.e.: requirements outside the scope of how it actually works / solves problems) are addressed in a later section.
Note that this section does not have to be filled out in detail to the extent that a “Change” would require (per the Changes process in Fedora.)
== Bucket List ==
* Per jwb's [https://lists.fedoraproject.org/pipermail/cloud/2013-October/002862.html mail] on 2013-10-30 - questions around kernel requirements need to be addressed at some point, wrt requests for a more minimal kernel for cloud images.
== Requirement #1 (Short Description of Requirement) ==
=== Feature(s) Addressed ===
Refer to which previously described Features, Use Cases this requirement helps to fulfill.
=== Priority ===
Must, should, NTH
=== Effort required ===
High, Medium, Low
=== Stakeholders / Owners ===
=== Major Dependencies ===
Any major dependencies, including things that may require any cross-working-group coordination, should be called out here. Any process changes required within Fedora should be documented here as well.
=== Testing ===
Level of testing required; is it a blocker to release?
Is the testing automate-able?
=== Other Documentation ===
* Existing BZ:
* Upstream webpage / wiki page / github page(s):
== Requirement #2 (Short Description of Requirement) ==
= Non-functional requirements =
These are the requirements needed that are not necessarily part of implementation of the product itself, but are still required as part of either making the product more attractive/useful, compatibility requirements for a user's workflow (ie: “works with Puppet,”) or things needing to be done/coordinated in other areas of the project (in other working groups?) to ensure a well-rounded solution.
For each, as was done with Features in a previous section, we should call out some additional information, assuming doing so makes sense for the requirement:
* Priority (Must, Should, NTH)
* Effort required
* Major dependencies / Process Changes needed
* Stakeholders/Owners
* Existing Documentation: BZ #, pointers to upstream project docs
== Image Creation ==
How to create images. Do not be shocked if there are 48 ways to do this. Also: not sure if we want to include containers in this section.
=== Creation of “official” Fedora Project images ===
New images. Updated images (ie: providing newer images for a release that have updates already included) might also be included here?
=== Images created by users ===
== Technical requirements ==
=== Configuration Management ===
=== Migration / Upgrades ===
=== Performance / Scalability / Failover ===
=  General requirements =
== Documentation ==
=== Fedora Project Documentation ===
=== Open Source Projects documentation ===
Ensuring that Fedora is well-represented, up-to-date in other open source project documentation...
== Release Criteria ==
= Technical requirements =
== Maintainability ==
== Support Requirements ==
=== Architectures Supported ===
=== Supported (platforms?) ===
Virtualization types? Container types?
== Internationalization / Localization ==
== Logging / Auditing ==
== Monitoring / Notification ==
== Database requirements ==
== Security ==
= About this Document =
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.
The actual governance of this document, and whether or not it is “fixed” at a certain point in time or able to evolve (in the form of updating progress, etc.) is still to be determined.
== Authors ==
Contributors to this document include:
* [[User:rbergero|Robyn Bergeron]]
* [[User:mattdm|Matthew Miller]]
* [[User:skottler|Sam Kottler]]
* [[User:Hguemar| Haïkel Guémar]]
== Reviewers & Contributors ==
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]]
==  Community Information ==
The Fedora Cloud SIG is one of many teams within the Fedora Project.
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.
== 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.
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.
* 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==
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.
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:
* Provide a secondary location where changes are tracked (which seems like a lot of overhead to me)
* 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.
* Scope out  how features are expected to progress over a number of releases.
* None of these things.
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.
== Document Conventions==
=== Definitions and Acronyms ===
* AWS: Amazon Web Services
* Amazon EC2: Amazon Elastic Compute Cloud, a popular public IaaS
* IaaS: Infrastructure as a Service
* PaaS: Platform as a Service
* SaaS: Software as a Service
* PRD: Product Requirements Document
* [[EPEL]]: Extra Packages for Enterprise Linux
* CI: Continuous Integration
* 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
=== Indication of prioritization ===
=== Other ===
* Items marked with a ? and following question in italicized lettering are open questions.

Latest revision as of 20:45, 1 November 2022

The Fedora Cloud Special Interest Group

Purpose and Demographic

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 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 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