Upstart helpers (abstract jobs and event aliases) for Oneiric

[Marc - A. Dahlhaus]

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?

> == 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
--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...

[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).

As all "Common Services" should be mutually exclusive installed, so each
of them can use the same alias stanza value.


Marc