UpstartJobAdministration
|
Size: 2567
Comment: "Use cases" should be "User stories" (see Wikipedia for more info)
|
← Revision 16 as of 2010-05-30 16:47:43 ⇥
Size: 5823
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ##(see the SpecSpec for an explanation) | |
| Line 3: | Line 2: |
| * '''Launchpad Entry''': UbuntuSpec:foo * '''Created''': * '''Contributors''': * '''Packages affected''': |
* '''Launchpad Entry''': UbuntuSpec:desktop-maverick-upstart-job-administration * '''Created''': 2010-05-24 * '''Contributors''': [[JacobPeddicord|Jacob Peddicord]] * '''Packages affected''': [[https://launchpad.net/jobsadmin|jobs-admin]], [[https://launchpad.net/jobservice|jobservice]] |
| Line 10: | Line 9: |
| This should provide an overview of the issue/functionality/change proposed here. Focus here on what will actually be DONE, summarising that so that other people don't have to read the whole spec. See also CategorySpec for examples. | ''This is a Google Summer of Code 2010 project.'' This spec consists of two main components: * A service administration and configuration UI (jobs-admin) * Configuration backend (jobservice) jobs-admin, in short, is a replacement for services-admin in gnome-system-tools but written with Upstart in mind. jobservice is a generic dbus backend for jobs-admin which talks to Upstart and manages service-level settings. Key features of jobs-admin and jobservice include: * Upstart 0.6, Upstart 0.10, and SysV compatability * Service-level settings: ability to easily set a setting for a specific service; ex. a document-root for apache2. This includes the proposed Upstart 0.10 overrides. * Start/stop/enable/disable services |
| Line 14: | Line 24: |
| This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.) It is mandatory. |
jobs-admin is a new application intended to replace the lost functionality of services-admin during the Upstart transition. It provides an user-friendly way to enable, disable, and change settings of services and jobs. jobs-admin is available at System > Administration > System Jobs. |
| Line 20: | Line 28: |
| This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified. | services-admin, a part of gnome-system-tools, exists for the purpose of simple service management. It uses system-tools-backends to handle the work of enabling and disabling services, and is able to use multiple backends. However, these backends are assumed to conform to a certain model that uses runlevels as a primary concept. Upstart does not depend on runlevels and so does not fit into this model very well. Attempts to implement Upstart support in system-tools-backends were unsuccessful or required strange workarounds. After discussions with the maintainer of gnome-system-tools, we will create a new set of utilities to manage services, keeping Upstart in mind from the beginning. As services-admin used to be available on the default CD distribution, it would be nice to see this available on-disc as well to bring back simple service administration. |
| Line 24: | Line 36: |
| * Jack wants to install a media server, but wants to be able to easily turn it on and off without using the terminal. * Sally wants to administer basic aspects of her home web server: she wants to be able to control when it's active and change the port that it runs on without trying to edit configuration files. * Fred needs to disable ureadahead, but isn't sure how. He should be able to turn it off with a few clicks. |
|
| Line 25: | Line 41: |
The current target systems are Maverick and Lucid (latter via PPA). We can assume that both will have some version of Upstart available and that both may still use some System V scripts. |
|
| Line 28: | Line 46: |
| You can have subsections that better describe specific parts of the issue. | jobservice exports available jobs over DBus in a manner that is easy to implement in any application. It abstracts the different service backends into one interface, removing the complexity of using services in an application. An average Maverick system using jobservice would have both upstart_0_10 and sysv backends active, but an application doesn't have to know to be able to use it effectively. jobservice will use PolicyKit for controlling access to job management. jobs-admin is an application that can take advantage of jobservice, and is the main application used when managing services/jobs. |
| Line 32: | Line 52: |
| This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: | Both jobservice and jobs-admin are implemented using Python. This ensures a small file size while being easy to develop and debug. jobservice will read "service-level settings" (''SLS'') from a system directory such as /usr/share/jobservice/sls. SLS files will have an XML-based format (for easy i18n) and will contain information on service setting names, descriptions, types, value constraints, and other variables needed to automate service configuration. Initially, jobservice will ship SLS files for common system services. This specification is being [[http://jacob.peddicord.net/2010/05/bringing-it-back.html|implemented by Jacob Peddicord]] as a [[http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/ubuntu/t127230763924|Google Summer of Code 2010 project]]. |
| Line 36: | Line 60: |
| Should cover changes required to the UI, or specific UI that is required to implement this | The jobs-admin UI is a simplistic GTK+ interface: {{attachment:jobadmin-mockup.png}} The main window on the left contains the main job listing (left) and job details (right). From this window a user can view information about when the job starts or manage it on their own. Clicking the "Service Settings" button will bring up the dialog on the right, which is dynamically generated from service-level settings shipped on the system. The interface is not final; the provided screenshot above is a Glade mockup. jobservice is only used over DBus, and does not provide any graphical interface other than the occasional PolicyKit popup. |
| Line 40: | Line 72: |
| Code changes should include an overview of what needs to change, and in some cases even the specific details. | Both jobs-admin and jobservice are new projects and do not require any changes to other packages. |
| Line 44: | Line 76: |
| Include: * data migration, if any * redirects from old URLs to new ones, if any * how users will be pointed to the new way of doing things, if necessary. |
Since service management has been absent from Ubuntu for several releases, there is no data to migrate. Users should be instructed to find the utility under System > Administration > System Jobs. |
| Line 51: | Line 80: |
| It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage. This need not be added or completed until the specification is nearing beta. |
Tests are planned via PPA once ready. |
| Line 57: | Line 84: |
| This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved. | Other packages that ship a service should also ship a service-level settings file for jobservice to parse and jobs-admin to present to the user. If a SLS file is already shipped by jobservice, the new package should add a "Replaces: jobservice" line to the packaging to overwrite the file. |
| Line 61: | Line 88: |
| Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected. |
Launchpad Entry: desktop-maverick-upstart-job-administration
Created: 2010-05-24
Contributors: Jacob Peddicord
Packages affected: jobs-admin, jobservice
Summary
This is a Google Summer of Code 2010 project.
This spec consists of two main components:
- A service administration and configuration UI (jobs-admin)
- Configuration backend (jobservice)
jobs-admin, in short, is a replacement for services-admin in gnome-system-tools but written with Upstart in mind. jobservice is a generic dbus backend for jobs-admin which talks to Upstart and manages service-level settings.
Key features of jobs-admin and jobservice include:
- Upstart 0.6, Upstart 0.10, and SysV compatability
- Service-level settings: ability to easily set a setting for a specific service; ex. a document-root for apache2. This includes the proposed Upstart 0.10 overrides.
- Start/stop/enable/disable services
Release Note
jobs-admin is a new application intended to replace the lost functionality of services-admin during the Upstart transition. It provides an user-friendly way to enable, disable, and change settings of services and jobs. jobs-admin is available at System > Administration > System Jobs.
Rationale
services-admin, a part of gnome-system-tools, exists for the purpose of simple service management. It uses system-tools-backends to handle the work of enabling and disabling services, and is able to use multiple backends. However, these backends are assumed to conform to a certain model that uses runlevels as a primary concept. Upstart does not depend on runlevels and so does not fit into this model very well. Attempts to implement Upstart support in system-tools-backends were unsuccessful or required strange workarounds.
After discussions with the maintainer of gnome-system-tools, we will create a new set of utilities to manage services, keeping Upstart in mind from the beginning.
As services-admin used to be available on the default CD distribution, it would be nice to see this available on-disc as well to bring back simple service administration.
User stories
- Jack wants to install a media server, but wants to be able to easily turn it on and off without using the terminal.
- Sally wants to administer basic aspects of her home web server: she wants to be able to control when it's active and change the port that it runs on without trying to edit configuration files.
- Fred needs to disable ureadahead, but isn't sure how. He should be able to turn it off with a few clicks.
Assumptions
The current target systems are Maverick and Lucid (latter via PPA). We can assume that both will have some version of Upstart available and that both may still use some System V scripts.
Design
jobservice exports available jobs over DBus in a manner that is easy to implement in any application. It abstracts the different service backends into one interface, removing the complexity of using services in an application. An average Maverick system using jobservice would have both upstart_0_10 and sysv backends active, but an application doesn't have to know to be able to use it effectively. jobservice will use PolicyKit for controlling access to job management.
jobs-admin is an application that can take advantage of jobservice, and is the main application used when managing services/jobs.
Implementation
Both jobservice and jobs-admin are implemented using Python. This ensures a small file size while being easy to develop and debug.
jobservice will read "service-level settings" (SLS) from a system directory such as /usr/share/jobservice/sls. SLS files will have an XML-based format (for easy i18n) and will contain information on service setting names, descriptions, types, value constraints, and other variables needed to automate service configuration. Initially, jobservice will ship SLS files for common system services.
This specification is being implemented by Jacob Peddicord as a Google Summer of Code 2010 project.
UI Changes
The jobs-admin UI is a simplistic GTK+ interface:
The main window on the left contains the main job listing (left) and job details (right). From this window a user can view information about when the job starts or manage it on their own. Clicking the "Service Settings" button will bring up the dialog on the right, which is dynamically generated from service-level settings shipped on the system.
The interface is not final; the provided screenshot above is a Glade mockup.
jobservice is only used over DBus, and does not provide any graphical interface other than the occasional PolicyKit popup.
Code Changes
Both jobs-admin and jobservice are new projects and do not require any changes to other packages.
Migration
Since service management has been absent from Ubuntu for several releases, there is no data to migrate. Users should be instructed to find the utility under System > Administration > System Jobs.
Test/Demo Plan
Tests are planned via PPA once ready.
Unresolved issues
Other packages that ship a service should also ship a service-level settings file for jobservice to parse and jobs-admin to present to the user. If a SLS file is already shipped by jobservice, the new package should add a "Replaces: jobservice" line to the packaging to overwrite the file.
BoF agenda and discussion
DesktopTeam/Specs/Maverick/UpstartJobAdministration (last edited 2010-05-30 16:47:43 by pool-96-230-20-221)