From Fedora Project Wiki
No edit summary
(→‎Product Objectives: Update the general statement)
 
(115 intermediate revisions by 12 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 -->
= 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.


= About this Document =
= Product Objectives =
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 ''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 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.
== 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.


== Authors ==
== Adaptations for Hyperscaler Use Cases ==
Contributors to this document include:
Some use cases may be considered as antithetical to the goals of other edition deployment
* [[User:rbergero|Robyn Bergeron]]
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.


== Reviewers & Contributors ==
At the 2020 Power Management and Scheduling in the Linux Kernel summit (OSPM)[1], Andrea
The following people have contributed to the development of this document, through feedback on IRC, mailing lists, and other points of contact.  
Righi and Rafael Wysocki discussed the use of hibernation on cloud-based systems and
* Your name here!
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.


==  Community Information ==
There are a number of example use cases to explore in both traditional and non-traditional
The Fedora Cloud SIG is one of many teams within the Fedora Project.
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.


The Cloud SIG mailing list is located [https://admin.fedoraproject.org/mailman/listinfo/cloud here.]
== 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.


Minutes and logs from IRC meetings related to the development of this document should be listed here as the document evolves.
=== An Example: Base Image optimized for use with cloud native Kubernetes services ===
== Approval History ==
Amongst the hyperscaler cloud infrastructures there are those services where a specialized
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.  
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.


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


* October 28, 2013: [http://fedoraproject.org/w/index.php?title=Cloud_PRD&oldid=358260 Initial Draft of template.]
For EDA, there is an expectation that a significant number of applications will run
* FutureDate: Approval by SomeGroup; link to any pertinent mail announcement and/or meeting minutes
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.


==Tracking of Progress==
== Focus on the familiarity of the users. ==
This document contains numerous descriptions of use cases, descriptions of feature sets to address the use cases, and the requirements to enable those features. It is expected that numerous requirements, better known as “changes” in the Fedora change process, or known even more simply as “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.  
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.


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


This document could possible be used to do any or a number of the following things:
== 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 [https://www.theopensourceway.org/ open source way].


* Provide a secondary location where changes are tracked (which seems like a lot of overhead to me)
Examples of opinionated models are the use of python 2.7 in Google's gcloud sdk or the practice
* 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.
of clobbering the systemd-acpid \`sleep.sh\` file in the Amazon Hibernation Agent. Simply
* Scope out  how features are expected to progress over a number of releases.
put, these are problems for the Cloud Edition to resolve and to help work with the
* None of these things.
upstream teams responsible to make their applications functional in the context of the
Fedora Distribution and downstream Enterprise Linux.


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


= Document Purpose and Overview =
= Architectural Considerations =
== What this document describes ==
== Boot Support ==
== Document Conventions==
* Legacy Bios or ''Classic Boot''
=== Questions within the space of this document are marked by a ? ===
* UEFI
=== Definitions and Acronyms ===
=== Indication of prioritization ===
== Document Structure ==


Overview of what each section in the PRD (should) contains.
  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.  


= Release/Product Overview =
== Processor Architecture Support ==
== Market Opportunity ==
* x86_64
== Product Objectives ==
* aarch64
Overview of product goes here.
=== Major Release Themes ===
=== Secondary Objectives ===
== Target Market / Audience ==
== Delivery Mechanisms ==
How we deliver the product. This has two facets:
=== Where to obtain ===
(FTP, website, AWS, etc.)
=== Delivery Format ===
(Images of various types, containers, etc.)
Note that delivery format is likely covered in more depth in other sections as well.
== Measuring Success ==


= User Profiles, Goals, and Primary Use Cases =
= Participants =
Still working out some logic on this section. But forging ahead with what I have for the moment.
Currently the following people are involved in the Cloud Working group.


Goal of this section is to provide insight into either or both of:
* [https://fedoraproject.org/wiki/User:Davdunc David Duncan]


* Primary Use Cases: What are the situations / environments in which we expect a Fedora Cloud Product to be used
* [https://fedoraproject.org/wiki/User:Dustymabe Dusty Mabe]
* 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 )


... and then ensure that for each type of user or use case, we have features/changes that make the Fedora Cloud product useful.
* [https://fedoraproject.org/wiki/User:Mhayden Major Hayden]
== User Profiles ==
=== User Profile #1 ===
# User Goals
What are this user's main goal in using this product?
# Common Tasks
What are the user's main tasks they need to accomplish with the product?
=== User Profile #2 ===
== Primary Use Cases ==
=== Primary Use Case #1 ===
* Problem Being Solved / Goal needing to be achieved
* Assumptions
* Workflow
=== Primary Use Case #2 ===


= Secondary Use Cases =
* [https://fedoraproject.org/wiki/User:Ngompa Neal Gompa]
Because cloud is “cloudy,” sometimes the cloud product requirements may be dependent on enablement in other Fedora products. Additionally, there may be open source projects with which we desire compability.  


Note that some of these secondary use cases may overlap with primary use cases. (Or this section may be entirely rolled into that section; TBD.)
* [https://fedoraproject.org/wiki/User:Dcavalca Davida Cavalca]


== IaaS environments ==
* [https://fedoraproject.org/wiki/User:Salimma Michel Salim]
Ensure that the Fedora Server product can serve as a platform for the following IaaS projects, or at least  that the Fedora Cloud product can be used as a guest/VM/image with those services. For projects that are not currently packaged within Fedora/EPEL, we may need to locate a kind person to ensure testing.
=== OpenStack ===
=== Eucalyptus ===
=== Apache Cloudstack ===
=== OpenNebula ===
== PaaS environments ==
=== OpenShift ===
== Big Data ==
== Development environments ==
Fedora should be a useful, productive environment for developers writing code to be executed in a cloud environment.
=== 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.
* [https://fedoraproject.org/wiki/User:Chrismurphy Chris Murphy]


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.”
* [https://blog.centos.org/2022/03/new-centos-director-amy-marrich/ Amy Marrich]


= Features =
* [https://fedoramagazine.org/joe-doss-how-do-you-fedora/ Joe Doss]
Features here address the primary and secondary use cases, product or secondary objectives,  market opportunities from above.


Features should be described as “what it enables” (poor description for now as I flesh out something better or someone else comes up with it!) - 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.
Many others have participated in the past and the projects a whole was
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
working on the scope and practices followed by the Cloud Working Group for many years.


== 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:
= Project Status =
Priority (Must, Should, NTH)
The Working group is '''ACTIVE'''
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.”
Currently the Cloud Working Group is focused on returning to status as
an [https://fedoraproject.org/wiki/Changes/RestoreCloudEdition 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 [https://projectatomic.io/ 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.


== Feature #2 ==
== 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.


= 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.
=== Footnotes ===


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.)
[1] https://lwn.net/Articles/821158/n
 
== 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 ===
 
== Installation/deployment requirements ==
== Configuration Management ==
== Migration / Upgrades ==
== Documentation ==
=== Fedora Project Documentation ===
=== Open Source Projects documentation ===
Ensuring that Fedora is well-represented, up-to-date in other open source project documentation...
== Performance / Scalability / Failover ==
== Maintainability ==
== Support Requirements ==
=== Architectures Supported ===
=== Supported (platforms?) ===
Virtualization types? Container types?
== Internationalization / Localization ==
== Logging / Auditing ==
== Monitoring / Notification ==
== Database requirements ==
== Security ==
 
= Release Criteria =

Latest revision as of 20:45, 1 November 2022

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

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