Upstart helpers (abstract jobs and event aliases) for Oneiric

[James Hunt]

Hi Marc,

On 07/06/11 20:15, Marc - A. Dahlhaus wrote:
> Am 07.06.2011 16:00, schrieb James Hunt:
>> Hi All,
> 
> Hi James,
> hi List,
> 
>> This mail turned into rather an epic in the writing. The summary is I'm
>> interested in thoughts on the two implementation options for "Proposal 2".
>>
>> Regards,
>>
>> James.
>>
>>
> --8<--
>> = Proposals =
>>
>> == Proposal 1: Provide Event Aliases for Common Scenarios ==
>>
>> Create event aliases as shown below:
>>
>> |----------------+------------------|
>> | Existing Event | Event Alias      |
>> |----------------+------------------|
>> | runlevel 0     | halt             |
>> | runlevel 1     | single-user-mode |
>> | runlevel S     | single-user-mode |
>> | runlevel 2     | multi-user-mode  |
>> | runlevel 6     | reboot           |
>> | runlevel [016] | shutdown         |
>> |----------------+------------------|
> 
> Will this events get emitted by upstart itself?
No, they don't need to be. Upstart has no concept of runlevels - they are just events. Hence, these
aliases would not be emitted by Upstart itself, but rather by a job configuration file, such as:

  start on runlevel

  task

  script
    case "$RUNLEVEL" in
      0)   events="shutdown halt";;
      1|S) events="shutdown single-user-mode";;
      2)   events="multi-user-mode";;
      6)   events="shutdown reboot";;
    esac

    for event in $events
    do
      initctl emit $event
    done
  end script

> 
>> == Proposal 2: Provide Abstract Jobs for Common Services ==
>>
>> |-----------------+-------------------------------------------------------------------|
>> | Abstract Job    | Description                                                       |
>> |-----------------+-------------------------------------------------------------------|
>> | display-manager | gdm, kdm, lightm, etc.                                            |
>> | network-manager | NetworkManager, wicd, connman, etc                                |
>> | firewall        | ufw alias.                                                        |
>> | network         | started when *all* configured network interfaces and bridges "up" |
>> | graphics-card   | starts when first graphics card added to system.                  |
>> |-----------------+-------------------------------------------------------------------|
>>
>> === Implementation ===
>>
>> There are two simple methods here we're considering.
>>
>> ==== Option 1 ====
>>
>> Update every package that provides a service such that its Job
>> Configuration File sets and exports a "well-known" variable. The
>> proposed list of environment variables which represent these services
>> is:
>>
>>   DISPLAY_MANAGER
>>   FIREWALL
>>   GRAPHICS_CARD
>>   NETWORK
>>   NETWORK_MANAGER
>>
>> For example, each display manager package would be updated such that its
>> .conf file specified:
>>
>>   env    DISPLAY_MANAGER=y
>>   export DISPLAY_MANAGER
>>
>> Then, any job that requires a display manager could say:
>>
>>   start on starting DISPLAY_MANAGER=y
We could make this slightly better by having /etc/init/display-manager.conf:

  start on starting DISPLAY_MANAGER=y
  stop  on stopped  DISPLAY_MANAGER=y

So that you could then say in foo.conf:

  start on starting display-manager

> --8<--
>> ==== Option 2 ====
>>
>> Create a Job Configuration File that hard-codes the list of known
>> service providers. For example for "display-manger", we could have:
>>
>>   start on (starting gdm
>>         or (starting kdm
>>         or (starting lightdm
>>         or (starting lxdm
>>         or (starting slim
>>         or (starting wdm
>>         or  starting xdm))))))
>>
>>   stop on (stopping gdm
>>         or (stopping kdm
>>         or (stopping lightdm
>>         or (stopping lxdm
>>         or (stopping slim
>>         or (stopping wdm
>>         or  stopping xdm))))))
>>
>>   env    ABSTRACT_JOB=y
>>   export ABSTRACT_JOB
> --8<--
> 
> Well, i don't like Options 1 and 2 as they look as hackish as the things
> you want to get rid of in the first place...
As I said, ugly. But they do have the benefit of extreme simplicity (kiss... :-)

> 
> [RFC] Option 3:
> 
> add an new "alias" stanza that sends an event (in parallel to all of the
> jobs main events) with JOB=$alias (and waits for booth to complete where
> appropriate).
I had already considered a slight variation but discounted it since as shown, you can provide
atleast a subset of the required behaviour without any changes to Upstart. However, having mused on
this, I'm coming round to the idea of an "alias" stanza since as you mention it allows initctl to
work as expected when the user says "start display-manager" and that is clearly important [1].

For the scenario where a user has, say, multiple display managers installed all of which specify:

  alias display-manager

Running "start display-manager" is clearly ambiguous. However, we could handle this by having
initctl fail immediately with an error such as:

$ start display-manager
start: ERROR: Alias display-manager resolves to multiple jobs (foo-dm, gdm, lightm)

This could then be resolved either manually...

$ start display-manager JOB=gdm
display-manager (gdm) start/running, process 1234

... Or, maybe by "forcing" start to select one of the providers:

$ start --force display-manager
start: Resolved alias display-manager to job foo-dm
display-manager (foo-dm) start/running, process 1234

We could also allow an optional job to be specified to the "alias" stanza such that we could create
/etc/init/abstractions.conf (or maybe allow content in /etc/init.conf):

  # this job cannot be started
  manual

  alias display-manager gdm
    :
  alias display-manager xdm


  alias network-manager connman
    :
  alias network-manager wicd

> 
> As all "Common Services" should be mutually exclusive installed,
We can't really make this assumption.

 so each
> of them can use the same alias stanza value.
> 
> 
> Marc

[1 - I think this is a key point since if we don't care that much about initctl not allowing us to
say "start <display manager>", the "alias" stanza doesn't really buy us much over the existing options.

Regards,

James.