upstart plans for F10+

[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