Job profiles (Was: Upstart 0.5 Are We There Yet?)
Tristan Wibberley
tristan at wibberley.org
Sat Jan 19 00:45:50 GMT 2008
On Fri, 2008-01-18 at 14:12 +0000, Scott James Remnant wrote:
...
> we appear to have reached the beginning of this conversation ;)
[suggestions 1-4 snipped]
5.) Define "patches" to job definitions allowing insertion of delay
jobs, addition of conjunction terms, changes to parameters including the
trigger condition. This could be a single file or a set of directories
mirroring the full configuration. There would be a "root" profile with
Ubuntu's eventual total-zerconf startup and then profiles based on that
- and maybe even profiles based on those.
This way you could prioritise particular jobs for, say, a kiosk.
Although that much would need some way to describe following whole job
trigger paths and manipulating all jobs on or not on those paths.
This mechanism can start truly simple and later easily grow in
sophistication as the need arises by initially supporting only simple
overriding of a job's trigger condition so it can be disabled.
5.1) A commandline tool should be provided to list related, redundant,
and orphaned patches. No GUI-only policy for /that/ tool please.
5.2) I wonder if a "current" profile should exist on disk from boot to
halt. It would be emptied on boot (tmpfs mount perhaps) and the profile
chosen on the kernel commandline (defaulting to root) would be set as
its parent. The admin could then configure patches affecting just the
currently running system to try out things adhoc and then copy the
profile to a named location in the upstart profiles directory when
they're happy with it - or even merge it down onto the parent as a
transaction like reconfiguring mechanism.
--
Tristan Wibberley
More information about the upstart-devel
mailing list