UpstartJobAdministration
2255
Comment: ## page was copied from SpecTemplate
|
5934
page was renamed from upstart-administration-service-configuration
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
## page was renamed from upstart-administration-service-configuration | |
Line 4: | Line 5: |
* '''Launchpad Entry''': UbuntuSpec:foo * '''Created''': * '''Contributors''': * '''Packages affected''': |
* '''Launchpad Entry''': UbuntuSpec:todo * '''Created''': 2010-05-24 * '''Contributors''': [[JacobPeddicord|Jacob Peddicord]] * '''Packages affected''': [[https://launchpad.net/jobsadmin|jobs-admin]], [[https://launchpad.net/jobservice|jobservice]] |
Line 11: | Line 12: |
''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 13: | Line 27: |
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 19: | Line 31: |
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 20: | Line 38: |
* 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 23: | Line 45: |
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 25: | Line 49: |
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 29: | Line 55: |
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 33: | Line 63: |
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 37: | Line 75: |
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 41: | Line 79: |
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 48: | Line 83: |
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 54: | Line 87: |
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 58: | Line 91: |
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: todo
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)