Upstart helpers (abstract jobs and event aliases) for Oneiric

[James Hunt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/06/11 02:35, Jan Claeys wrote:
> James Hunt schreef op di 07-06-2011 om 15:00 [+0100]:
>> === 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
>>
>> ===== Observations =====
>>
>> - This might *appear* to be inefficient in that Upstart must check every
>>   time *any* job starts to determine if DISPLAY_MANAGER=y is set in that
>>   jobs environment. However, there is no additional overhead beyond how
>>   Upstart currently works. Consider that...
>>
>>     start on starting gdm
>>
>>   ... is actually an alias for:
>>
>>     start on stating JOB=gdm
>>
>> - This would require *every* package that provides a service to be
>>   updated. Admittedly this would only need to be done once though.
> 
> At least for every package that wants to support this...
> 
>> - Might be confusing since users you *must* specify "=y" exactly
>>   (dropping the "=y" won't work, and nor will specifying "=Y" (or "=1")).
> 
> So, why not use something like SYSTEM_SERVICE=display-manager instead?
> That would be less confusing...
Agreed.

> 
> 
> The main disadvantage for this is that the start/stop/etc. command don't
> work without a job name.  So you can't do a 'restart firewall', but you
> have to check what firewall service is running, and then  restart that
> job.  I'm not 100% sure this is bad or good though (services might have
> different (default) behaviour despite providing the same service)?
Also a good point. They should of course all provide a common subset of whatever service they do
provide (a firewall is expected to block ports, a DM to display a graphical login prompt, etc), but
this exercise could well be somewhat of a learning experience. However, note that the small set of
abstractions that we've identified so far [1] should help avoid future surprises there as most of
them have been identified from common categories of bugs we have seen.

[1] - We're also planning to audit all existing .conf files in Ubuntu  and convert SysV services to
jobs in Ubuntu main were possible. This work may well identify other idioms and thus further
abstractions.

> 
> 
>> ==== 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
>>
>> ===== Observations =====
>>
>> - Since this is an Abstract Job, it will have no PID, but this job will
>>   "run" for the duration of the first display manager to be invoked.
>>
>> - We appear to have simply "moved the problem" since although we are no
>>   longer hard-coding the list of display managers in "plymouth.conf", we
>>   are hard-coding the list now in "display-manager.conf". However, we
>>   have gained by doing this since:
>>
>>   - We have still created the level of abstraction desired.
>>   - We have contained the problem into a single file: we define the list
>>     of display managers *once*.
>>   - We don't need to update every Ubuntu (and potentially every Debian)
>>     package as would be required for "Option 1".
>>   - We *could* conceivably auto-generate "display-manager.conf" from the
>>     archive with a simple script which munged the output of:
>>
>>     apt-cache search x-display-manager|awk '{print $1}'|sort
> 
> For some reason this doesn't give a complete list of all display
> managers in the repository (maybe some of them aren't meant to be run at
> boot like that, but some certainly do--that might be a bug in those
> packages?), but more importantly this will never include display
> managers that aren't in the official repositories.
> 
>> - The "ABSTRACT_JOB" variable would allow other jobs to detect that a
>>   job was abstract (they shouldn't need to care, but just in case...)
>>   This also avoids the unwieldliness of "abstract-display-manager" (or
>>   even "abstract/display-manager" (were we to put the abstract jobs in
>>   /etc/init/abstract/ say).
> 
> 


- -- 
Cheers,

James.
- --
James Hunt
____________________________________
Ubuntu Foundations Team, Canonical.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3vfbUACgkQYBWEaHcQG9fFJwCeI+vjYcvzizqm6YGnRSUgHOip
mHgAmwbBdr+KOpDmGZpt8rEyZ0KFYhri
=G62y
-----END PGP SIGNATURE-----