Server/Product Requirements Document

This is the 2014 version of this document. Unless you are doing historical research, see the 2021 Fedora Server Edition PRD

Document Purpose and Overview

What this document describes

This is the Product Requirements Document for the Fedora Server. It:

• Provides a high-level market overview of the infrastructure server market as it pertains to the Fedora Server; this includes items which may not be within our actual scope/ability to accomplish at the current time.
• Provides deeper understanding of the types of users who could use Fedora for their application and infrastructure 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.
• Ties common issues and needs of potential users/consumers of the Fedora Server product to high-level product needs, from a "functional" standpoint.

This document does not dictate implementation details. The goals in this document will drive the continued implementation of this product.

Fedora Server Vision Statement

Fedora Server is the preferred [community] platform for system administrators and developers seeking to deploy applications and services that use the latest technology on a stable foundation with effective resource utilization.

Fedora Server Mission Statement

Fedora Server is a common base platform with "featured server roles" built on top of it. We commit to produce, test, and distribute these server roles.

Market Opportunity

The server operating system market is mature, but constantly evolving. Fedora Server has opportunity for adoption as people deploy new applications and services as well as migrate legacy applications to new platforms.

With the increased complexity of IT and software, system administrators find it more difficult to devote large amounts of time to dealing with individual technologies, specifically:

• Detailed understanding of the underlying technology, as has traditionally been required for Open Source server solutions, is often not feasible.
• The constant focus of Fedora to ship the latest upstream releases of software, combined with a short lifecycle and lack of tooling, require frequently spending significant amounts of time migrating from one Fedora release to another.

These impositions on system administrators are a significant barrier to further growth of Fedora, and we believe that by improving the product we can remove these requirements and barriers, opening Fedora up to a much larger user base that has so far been limited to non-Linux server solutions.

Fedora, being a leading-edge Linux distribution, is the ideal place to design such server improvements for the Linux ecosystem together with real-world users to make them available to early adopters.

Product Objectives

Fedora Server consists of a release that can be used at various scales. For example, it could be used in the following example environments:

• A single server that runs an application or service.
• A platform for an entire data center.
• The platform to deploy an Infrastructure-as-a-Service (IaaS) private cloud.

Fedora Server is meant to be used for the following purposes:

• An operating platform for important infrastructure tasks (DNS, DHCP, etc.) and server applications (file/storage server, database server, user-developed web applications, etc.)
• A platform for deploying Infrastructure-as-a-Service systems for best deployment of Fedora Cloud images.
• Infrastructure to allow efficiently managing many servers as a single unit. The product only commits to producing basic tools, but the infrastructure will allow more advanced tools to be created.

The Fedora Server product will also provide one or more "roles" that can be used to easily spin up a service or application. Roles will be introduced gradually as development and testing allow, but it is a primary objective to offer useful roles built on top of the base server offering. More information about what roles are is provided elsewhere in this document.

Secondary Objectives

Aside from the adoption and development of applications on top of the Fedora Server platform, we have a few secondary goals that should be helped by wider adoption:

• More testing of Fedora images with additional bug reports.
• Better feedback about product direction and potential improvements. 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.
• More 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.

User Profiles, Primary Use Cases and Goals

Personas

We will use a set of personas to describe our target users and their respective needs. This document will list the personas in their simplified forms, with detailed explanations of each one available on their respective wiki pages.

1. System Administrator "Macgyver"
   • Administrator with limited hardware and personnel resources to work with
   • Needs to be able to do "a lot with a little"
2. DevOps Engineer/Administrator
   • Focus is on time-to-deploy and time-to-recover as opposed to uptime
   • Value is achieved by delivering the latest capabilities fastest
   • Needs to be able to deliver quickly to PaaS, SaaS and bare-metal servers
3. Traditional Application Developer
   • Needs a platform with API and ABI stability guarantees
   • Focus will be on minimizing risk when making changes
   • Cannot tolerate rapid changes in core functionality
4. Junior Enterprise System Administrator
   • Simplify automation to manage repetitive tasks
   • Needs intuitive mechanisms to effect common changes
5. Decision Maker
   • Makes purchasing decisions and directs technology choices
   • Interacts with upstream FOSS communities to identify potential value

Use Cases

The Fedora Server will need to address the following use-cases:

1. The user must be able to easily deploy and configure any supported Fedora Server role. (Examples may include: FreeIPA Domain Controller, BIND DNS, DHCP, Database server, iSCSI target, File/Storage server, OpenStack Hypervisor Node.)
2. The user must be able to query, monitor, configure and manage a Fedora Server remotely using stable and consistent public interfaces.
3. The user must be able to simply enroll the Fedora Server into a FreeIPA or Active Directory domain.
4. Users must be able to control and contain the resources consumed by services running on the system.
5. Users must be able to rapidly re-deploy services in accordance with their DevOps practices using Fedora Server.
6. Users must be able to create, manipulate and terminate large numbers of containers using a stable and consistent interface.
7. The user must be able to install and manage Fedora Server in a headless mode where the display framework is inactive.

Featured Server Roles

A Featured Server role is an installable component of Fedora Server that provides a well-integrated service on top of the Fedora Server platform. These prepared roles simplify deployment and management of a service compared to setting up an upstream server from scratch; their use is recommended but optional; existing users of upstream servers based on Fedora RPMs will not be impeded.

Initially, we will test and support only a single role per server; installing several non-conflicting roles is expected, but we will not be testing every combination.

Mandatory Requirements

Mandatory requirements are exactly as they sound: if any one of these requirements is not met, the server role is ineligible for elevation to "featured" status.

1. The Server Role must be packaged in such a way that it is possible to install the complete set as a unit. AKA "One-click Install". [Use Case 1]
2. The Server Role must provide an API or similar stable external interface for configuring the role post-installation. Exceptions to this rule may be granted if and only if Optional Requirement 2 (below) is met and it can be demonstrated that the default method of operation is the only reasonable method of operation. [Use Case 1]
   • If the API is provided by the Fedora project it must be built using a common framework to all Fedora developed Role APIs. If upstream provides such an API, it is permissible to use that.
3. The Server Role must provide an API to interrogate the configurable settings of the role as identified by Mandatory Requirement 2. [Use Case 2]
4. The Server Role must add to the functionality of the Fedora Server. In other words, a Server Role cannot be considered "Featured" if its purpose is to further reduce the minimal system.
5. A Server Role must have an identified point of contact that agrees to maintain the Server Role in Fedora. If this person or group becomes unresponsive, the Server Role will necessarily be demoted from Featured status. A Server role must be possible to trivially update to fix security vulnerabilities, and maintained to provide security fixes in a timely manner.
6. A Server Role must be installable without a local graphical utility. [Use Case 7]
7. If a Server Role packages multiple upstream projects together as a suite or solution, updates to any of these projects must be coordinated for concurrent release to allow testing of the complete system.
8. A Server Role must automatically use and sufficiently implement specified system-wide settings (e.g. a LDAP source for account information, CA certificates, and similar domain-originated or system-wide configuration)

Conditional Requirements

This is not a list of things you should ignore. Rather, this is a list of things that if you implement them, you are committing that they must continue to behave that way in the future.

1. The Server Role may be packaged in such a way that it can be uninstalled as a complete unit. The mechanism to accomplish this removal must remain consistent. [Use Case 1]
2. The Server Role may provide a sane, usable default. If it does so, it must remain capable of accepting input through its configuration API to change this default. [Use Case 1]
3. The Server Role may provide an API to interrogate additional useful information about the running service(s) provided by the Server Role. The content here is up to the Server Role to define, but should be treated as stable (e.g an update should never remove the ability to monitor something). [Use Case 2]
4. The Server Role may provide a specification of its needed resources to the Fedora Server in a standard format. (e.g. Memory requirements) If this is provided, the Fedora Server may use this information to create isolated services such as VMs or containers in which to run the Server Role. [Use Case 4]
5. The Server Role may request operation in an isolated environment (with or without implementing Optional Requirement 4). If it does so, the Server Role must indicate (using a standard Fedora Server API) what form(s) of isolation it supports. Fedora Server must honor this. [Use Case 4]
6. A Server Role may provide a remote graphical (which includes web-based) configuration tool.
7. A Server Role may implement all of the other requirements by integrating with the Fedora Server-designated infrastructure (commands, APIs, and the like). This is preferred but not mandatory if the upstream provides a different way to achieve the same objective.

Logistical Concerns

Delivery Mechanisms

Fedora Server will produce two main installation resources, a netinstall image and an offline install iso image that allows one to install and configure featured roles offline.

Supported installation methods:

• Automated ("mass") install within a larger Linux infrastructure (e.g. PXE is an option, may have LDAP/IPA).
• Manual install without a supporting infrastructure (e.g. the very first Linux server).
• Where possible, existing servers and installed roles should be upgradable to new releases with minimal involvement by the admin.
• Individual roles should be installable at server install time (e.g. in Anaconda) and post-install.

Where to obtain

Users will be able to obtain these images from the Fedora Project website and mirror networks.

Measuring Success

In order to measure success we will monitor (somewhat arbitrary) numbers over time. The list of metrics we take in account will be adapted over time to measure specific efforts within the framework of the Server Working Group goals.

The initial basic set of metrics will be:

• Usage of Fedora Server images in AWS or other public cloud providers that publish such aggregated data.
• Number of contributors that explicitly contribute to the Fedora Server effort in some way. We'll try to gather data from sources that are easily measurable (commits, builds, etc..).
• Number of third party repositories or projects that decide to target Fedora Server.

This last point may be a stretch goal - admittedly it will require some time before this becomes really measurable, but in a 2-year time frame this kind of adoption should be discernable.

About this Document

Authors

Contributors to this document include:

• Stephen Gallagher
• Jim Perrin
• David Strauss
• Truong Anh. Tuan
• Máirín Duffy
• Kevin Fenzi
• Miloslav Trmač
• Simo Sorce
• Adam Williamson
• Joe Brockmeier