Differences between revisions 3 and 4
Revision 3 as of 2007-04-26 09:20:12
Size: 2689
Editor: MildredKilya
Revision 4 as of 2011-08-26 04:10:17
Size: 2689
Editor: localhost
Comment: converted to 1.6 markup
No differences found!

I'm not happy with the design of ComplexEventConfig, so I want to try and capture the use cases we're actually trying to solve, and how they should behave. Then we can work out what we actually want.

  • Task to mount a disk is run on the fstab-device-added event, and needs the information from that event to know which device to mount. However it's possible that it's not possible to mount that device yet, because a path above it in the tree isn't mounted yet. It should be possible for the task to fail, and be run again on subsequent path-mounted events. Optionally we might want the information from the second event as well to decide whether to bother trying (e.g. /var mounted when waiting for /usr, little point waiting).

    • fstab-device-event information needed until task is complete.

    • Probably want to block the event too, since this is the task that handles it.
    • Don't want to fail it immediately, since we can try again later.
    • Optionally include filesystem-mounted event information, you'd certainly want to know that it was that event.

    • If we block that event, we only want to block it until we have the job running since we might not care about this event.
  • Various web-related services will only need to be running when both the web server and database server are running. These services need to be stopped before either server can be stopped.
    • Both stopping events should block.

  • Many services require both networking and a filesystem. Networking might be defined as the period between a network-up and a network-down event. Filesystem might be a job that should be running, or might be defined as the period between two events.

    • Periods between events ("states") need to be first-class.
    • Jobs should also define these states, either as the period between its started and stopping events or just directly referencing the job state. (If filesystem is a job, it can't be its goal).

    • Combinations of events and states need to be legal (X needs to be started with a filesystem when certain tasks are complete).
  • lrm-manager needs to be run before we can start udevtrigger or read /etc/modules.

    • If this is done from those jobs, then there needs to be a way to mark something optional only if a job exists; since lrm-manager is not required.

    • Alternatively lrm-manager should be able to be started by either, blocking the starting event; but only run once.

  • Some services need to be restarted when something changes in the system (represented by an event). it should be possible to specify it.

ComplexEventConfig/UseCases (last edited 2011-08-26 04:10:17 by localhost)