-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
In order to seed the conversation for tomorrow's Server WG meeting, I'm putting together a first draft of a document outlining the requirements that must be met in order to promote an application/server technology into a featured role of the Fedora Server. Note: this must not preclude the ability for services not considered "Featured" to deploy on Fedora Server.
I will tie these goals to the agreed-upon use-cases where appropriate (see https://fedoraproject.org/w/index.php?title=Server/Use_Cases&oldid=36523... for the numbering reference).
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. Optional requirements are different. 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 list below should make this more clear).
This is a first draft, please add or criticize as necessary.
== Mandatory Requirements == 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]
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.
6. A Server Role *must* be installable without a local graphical utility. [Use Case 9]
== Optional Requirements == 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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I forgot an important one. Inline below.
On 01/06/2014 04:46 PM, Stephen Gallagher wrote:
In order to seed the conversation for tomorrow's Server WG meeting, I'm putting together a first draft of a document outlining the requirements that must be met in order to promote an application/server technology into a featured role of the Fedora Server. Note: this must not preclude the ability for services not considered "Featured" to deploy on Fedora Server.
I will tie these goals to the agreed-upon use-cases where appropriate (see https://fedoraproject.org/w/index.php?title=Server/Use_Cases&oldid=36523...
for the numbering reference).
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. Optional requirements are different. 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 list below should make this more clear).
This is a first draft, please add or criticize as necessary.
== Mandatory Requirements == 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]
- 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 to interrogate the
configurable settings of the role as identified by Mandatory Requirement 2. [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.
- 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 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.[1]
== Optional Requirements == 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]
- 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 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 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* 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]
- A Server Role *may* provide a remote graphical (which includes
web-based) configuration tool.
[1] This may mean that Server Roles support "bundling" in some limited sense; This may be as simple as packages having strict version requirements. I am electing not to specify an implementation here.
server@lists.fedoraproject.org
-
Stephen Gallagher