From Fedora Project Wiki
No edit summary
(Update use-case links)
Line 38: Line 38:


The Fedora Server will need to address the following use-cases: (Note: need to order these by priority)
The Fedora Server will need to address the following use-cases: (Note: need to order these by priority)
# 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.)
# {{Anchor|usecase1}}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.)
# The user must be able to query, monitor, configure and manage a Fedora Server remotely using stable and consistent public interfaces.
# {{Anchor|usecase2}}The user must be able to query, monitor, configure and manage a Fedora Server remotely using stable and consistent public interfaces.
# The user must be able to simply enroll the Fedora Server into a FreeIPA or Active Directory domain.
# {{Anchor|usecase3}}The user must be able to simply enroll the Fedora Server into a FreeIPA or Active Directory domain.
# Users must be able to control and contain the resources consumed by services running on the system.
# {{Anchor|usecase4}}Users must be able to control and contain the resources consumed by services running on the system.
# Users must be able to rapidly re-deploy services in accordance with their DevOps practices using Fedora Server.
# {{Anchor|usecase5}}Users must be able to rapidly re-deploy services in accordance with their DevOps practices using Fedora Server.
# ASK SOFTWARE COLLECTIONS WG The  user must be able to easily deploy and configure applications to  supported high-value frameworks. (Example frameworks: JBoss, Ruby on  Rails, Django, Turbogears, Node.js, PHP.)
# {{Anchor|usecase6}}ASK SOFTWARE COLLECTIONS WG The  user must be able to easily deploy and configure applications to  supported high-value frameworks. (Example frameworks: JBoss, Ruby on  Rails, Django, Turbogears, Node.js, PHP.)
# ASK CLOUD WG Provide a platform for acting as a node in an OpenStack rack.
# {{Anchor|usecase7}}ASK CLOUD WG Provide a platform for acting as a node in an OpenStack rack.
# ASK CLOUD WG Users must be able to create, manipulate and terminate large numbers of containers using a stable and consistent interface.
# {{Anchor|usecase8}}ASK CLOUD WG Users must be able to create, manipulate and terminate large numbers of containers using a stable and consistent interface.
# Users must be able to use Fedora Server in  fully headless operation.  We commit to supporting only those GUI  applications that can work with  forwarded X (or the equivalent on other  windowing systems)
# {{Anchor|usecase9}}Users must be able to use Fedora Server in  fully headless operation.  We commit to supporting only those GUI  applications that can work with  forwarded X (or the equivalent on other  windowing systems)


= [[Server/Proposals/Server_Lifecycle | Product Lifecycle]] =
= [[Server/Proposals/Server_Lifecycle | Product Lifecycle]] =
Line 68: Line 68:
{{admon/important | 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.}}
{{admon/important | 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.}}


# 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]
# 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". [[#usecase1| [Use Case 1]]]
# 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]
# 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. [[#usecase1| [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.
## 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.
# The Server Role '''must''' provide an API to interrogate the configurable settings of the role as identified by Mandatory Requirement 2. [Use Case 2]
# The Server Role '''must''' provide an API to interrogate the configurable settings of the role as identified by Mandatory Requirement 2. [[#usecase2| [Use Case 2]]]
# 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.
# 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.
# 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 timely.
# 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 timely.
# A Server Role '''must''' be installable without a local graphical utility. [Use Case 9]
# A Server Role '''must''' be installable without a local graphical utility. [[#usecase1| [Use Case 9]]]
# 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.
# 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.
# 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)
# 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)
Line 81: Line 81:
{{admon/important | 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.}}
{{admon/important | 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.}}


# 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]
# 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. [[#usecase1| [Use Case 1]]]
# 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]
# 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. [[#usecase1| [Use Case 1]]]
# 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]
# 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). [[#usecase1| [Use Case 2]]]
# The Server Role '''may''' provide a specification of its needed resources to the Fedora Server in a standard format. (e.g. Memory requirements, etc.) 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]
# The Server Role '''may''' provide a specification of its needed resources to the Fedora Server in a standard format. (e.g. Memory requirements, etc.) 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. [[#usecase1| [Use Case 4]]]
# 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]
# 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. [[#usecase1| [Use Case 4]]]
# A Server Role '''may''' provide a remote graphical (which includes web-based) configuration tool.
# A Server Role '''may''' provide a remote graphical (which includes web-based) configuration tool.
# 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.
# 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.


The original etherpad for this discussion is located at https://pad.riseup.net/p/serverwg-roles-proposal
The original etherpad for this discussion is located at https://pad.riseup.net/p/serverwg-roles-proposal

Revision as of 18:09, 7 January 2014

Warning.png

Our primary deliverable for January should be the definition of how we're going to prepare the platform and the requirements for an application stack to be promoted to first-tier inclusion. (Agreed 5 Nov 2013)

Mission Statement

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

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: (Note: need to order these by priority)

  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.)
  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. ASK SOFTWARE COLLECTIONS WG The user must be able to easily deploy and configure applications to supported high-value frameworks. (Example frameworks: JBoss, Ruby on Rails, Django, Turbogears, Node.js, PHP.)
  7. ASK CLOUD WG Provide a platform for acting as a node in an OpenStack rack.
  8. ASK CLOUD WG Users must be able to create, manipulate and terminate large numbers of containers using a stable and consistent interface.
  9. Users must be able to use Fedora Server in fully headless operation. We commit to supporting only those GUI applications that can work with forwarded X (or the equivalent on other windowing systems)

Product Lifecycle

See Server Lifecycle Proposal for draft work.

Delivery Mechanism

See Server Lifecycle Proposal for draft work that includes this topic.

Proposed Server Roles

See Server Roles Proposal for draft work.

Requirements for First-Tier Applications/Services Supporting a Server Role

Mandatory Requirements

Important.png
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]
    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 timely.
  6. A Server Role must be installable without a local graphical utility. [Use Case 9]
  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

Important.png
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, etc.) 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.

The original etherpad for this discussion is located at https://pad.riseup.net/p/serverwg-roles-proposal

Retrieved from "https://fedoraproject.org/w/index.php?title=Server/Product_Requirements_Document&oldid=366083"