upstart plans for F10+

[Konrad Meyer]

Quoth Bill Nottingham:
> Since I've been asked in various places what we're planning to 
> do with upstart now that Fedora 9 has shipped, I figured I'd
> lay out the basic plan.
> 
> To do any large-scale conversion of SysV init scripts to upstart,
> we need some features that are not in the current (0.3.9) version.
> Hence, the first thing is to get upstart 0.5 ready for inclusion.
> For example, we need support for the following:
> 
> - Depending on multiple events
> 
>   I.e., have something start only if two separate events have
>   both completed successfully. For a disturbing example of how
>   we work around this now, read /etc/event.d/serial.
> 
> - Ability to enable/disable events in a way other than removing
>   the file
> 
>   (The reasoning for this should be fairly obvious)
> 
> - Ability to group events into sets, or profiles
> 
>   This allows us to handle the sort of behaviors that runlevels are
>   used for sanely.
> 
> - Ability to easily have upstart events depend on SysV scripts, and
>   vice-versa
> 
>   If one of a SysV scripts' dependencies is started by upstart, we
>   need to be able to still handle that sanely.
> 
> This isn't meant to be an exhaustive list, but it is meant to
> illustrate why we can't just move services right now.
> 
> Once we get upstart 0.5 in, we can then look at potentially moving
> some subset of things that are now handled elsewhere to upstart.
> Examples would be:
> 
> - Always-on services such as dbus, syslog, and audit
> - Reworking things like netfs to be more sane, when
>   it comes to networks coming and going, network block devices being
>   attached and detached, and so on
> - Potentially splitting some of rc.sysinit into multiple events.
>   Not sure this buys us much, as right now the flow is *extremely*
>   sequential (start_udev -> fsck -> remount r/w -> clean out /tmp)
> - Coming up with a sane network notification strategy
>   Right now, we have events kicked off on network changes:
>   - via netreport
>   - via NetworkManagerDispatcher
>   - conceivably, via upstart (after all, spawning commands/etc based
>     on events is its raison d'etre)
>   Having a coherent strategy for apps to only need to worry about
>   dropping things in one place would make sense.
> - (possibly) having either upstart 'handle' sysv services more natively
>   or wrap tools such as chkconfig, /sbin/service so they handle both
>   SysV and upstart.
> 
> All clear as mud?
> 
> Bill


Thanks for keeping us informed of the current state of (upstart) affairs.

-- 
Conrad Meyer <konrad at tylerc.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080522/258380a4/attachment.sig>