From Fedora Project Wiki
(minor wording tweak) |
(flesh out some sections) |
||
| Line 36: | Line 36: | ||
== Detailed Description == | == Detailed Description == | ||
A new D-Bus service will be made available, exposing available server roles, making it possible to deploy, configure and manage them. | A new D-Bus service will be made available, exposing available server roles, making it possible to deploy, configure and manage them. | ||
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | <!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | ||
== Benefit to Fedora == | == Benefit to Fedora == | ||
A common framework will allow multiple tools to deploy and configure roles at various times, without conflict. We expect this framework will be used by the installer and also by end-user tools including a command-line tool and probably higher-level tools like Cockpit. | |||
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--> | <!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--> | ||
| Line 46: | Line 47: | ||
<!-- What work do the developers have to accomplish to complete the change in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the developers have to accomplish to complete the change in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
* Proposal owners: | * Proposal owners: Write, document, package and test the D-Bus API. | ||
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
| Line 59: | Line 60: | ||
== Upgrade/compatibility impact == | == Upgrade/compatibility impact == | ||
This is new functionality, so no impact on upgrades from previous releases. | This is new functionality, so we envisage no impact on upgrades from previous releases. | ||
The newly introduced user-facing API is intended to be long-term, available also in future releases of Fedora without breaking applications that use it as documented. (Note that the same promise is not given for the API used to implement the server roles.) | The newly introduced user-facing API is intended to be long-term, available also in future releases of Fedora without breaking applications that use it as documented. (Note that the same promise is not given for the API used to implement the server roles.) | ||
== How To Test == | == How To Test == | ||
The API should be relatively easily testable in a VM without special hardware or configuration. Test procedure would be more or less to do a basic/minimal install, install the relevant package, and then test that roles can be deployed and configured via direct D-Bus message injection (using dbus-send, dbus-monitor etc). | |||
Indirect testing of the API will also likely become part of Server validation testing, as role deployment and configuration are likely to figure prominently in that testing, and will run through the API. | |||
<!-- adamw thought: should we consider CI and regression testing in developing the API itself? --> | |||
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. | <!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. | ||
| Line 79: | Line 86: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
== User Experience == | == User Experience == | ||
This Change will not be directly visible in typical server admin tasks. | |||
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --> | <!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --> | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
== Dependencies == | == Dependencies == | ||
Revision as of 18:58, 1 April 2014
Framework for Server Role Deployment
Summary
A new D-Bus service, and associated command-line tools, to deploy and manage Server Roles.
Owner
- Name: Fedora Server Working Group
- Email: server AT lists DOT fedoraproject DOT org
- Release notes owner:
- Product: Server
- Responsible WG: Server
Current status
- Targeted release: Fedora 21
- Last updated: April 1, 2014
- Tracker bug: <will be assigned by the Wrangler>
Detailed Description
A new D-Bus service will be made available, exposing available server roles, making it possible to deploy, configure and manage them.
Benefit to Fedora
A common framework will allow multiple tools to deploy and configure roles at various times, without conflict. We expect this framework will be used by the installer and also by end-user tools including a command-line tool and probably higher-level tools like Cockpit.
Scope
- Proposal owners: Write, document, package and test the D-Bus API.
- Other developers: N/A (not a System Wide Change)
- Release engineering: N/A (not a System Wide Change)
- Policies and guidelines: N/A (not a System Wide Change)
Upgrade/compatibility impact
This is new functionality, so we envisage no impact on upgrades from previous releases.
The newly introduced user-facing API is intended to be long-term, available also in future releases of Fedora without breaking applications that use it as documented. (Note that the same promise is not given for the API used to implement the server roles.)
How To Test
The API should be relatively easily testable in a VM without special hardware or configuration. Test procedure would be more or less to do a basic/minimal install, install the relevant package, and then test that roles can be deployed and configured via direct D-Bus message injection (using dbus-send, dbus-monitor etc).
Indirect testing of the API will also likely become part of Server validation testing, as role deployment and configuration are likely to figure prominently in that testing, and will run through the API.
User Experience
This Change will not be directly visible in typical server admin tasks.
Dependencies
N/A (not a System Wide Change)
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? N/A (not a System Wide Change), Yes/No
- Blocks product? product
Documentation
N/A (not a System Wide Change)