Differences between revisions 2 and 3
Revision 2 as of 2007-02-25 09:59:32
Size: 2486
Editor: scott
Comment: more stuff
Revision 3 as of 2007-04-26 09:20:12
Size: 2689
Editor: MildredKilya
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
 * 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.
 * 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.
Line 11: Line 11:
  * Both `stopping` events should block.   * Both {{{stopping}}} events should block.
Line 13: Line 13:
 * 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).
 * 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).
Line 18: Line 18:
 * `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.
 * {{{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.

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 2007-04-26 09:20:12 by MildredKilya)