Ubuntu Wiki

• 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. It 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.

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 (the 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

You can have subsections that better describe specific parts of the issue.

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Migration

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.

Test/Demo Plan

Tests are planned via PPAs once ready.

Unresolved issues

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.

BoF agenda and discussion

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.

CategorySpec