Upstart 1.0 Design discussion

[Scott James Remnant]

On Sat, 2009-09-12 at 03:13 +0100, Scott James Remnant wrote:

> What are these events?  Well, it's still useful to be able to do this
> based on the state transitions of other jobs.  Take a "postgresql backup
> script" as an example:
> 
> 	while filesystem
> 	on postgresql post-stop
> 
> This shows how the "while" and "on" are distinct.  We want this to be
> stopped should the filesystem go away, but don't want any stopping to
> happen based on the state of postgresql - just starting.
> 
Another interesting thing abouts events is that they too have a
lifecycle and different states.

They're not just fired and forgotten: the event is kept "open" all the
time that jobs that it changed are in transition between levels.  Only
once the jobs are all back at a rest level again is the event finished.

This means that events can "fail" as well.


initctl blocks until the event is finished.

When the event is part of a job's state change away from a rest state,
the job itself waits for the event to finish before actually beginning
the transition.

It's this "blocking" behaviour that allows the events to be truly useful
for expressing dependencies.  Since a "dependency" job will not be
stopped until all things that depend on it are stopped, and a job with
an inserted "before" dependency will not be started until all the before
deps are started.


This has to be true for "while" as well as "on", and that's why I don't
think it makes sense to think of events as separate to jobs at all.  The
same underlying mechanism that triggers events and the "on" clause will
alter the "while" conditions, it has to be the same mechanism, because
it has to block.

From the simplest POV, the following have the same effect:

	while apache

and

	from apache post-start until apache pre-stop


Now, it gets more interesting if we bring the "start" and "stop"
commands into it.  Both have attached environment, just like events.
Both cause instances to be started or stopped, just like events.  Both
have blocking behaviour, just like events.  Both can finish
successfully, or fail, just like events.

The only difference is that start and stop commands are directed at a
specific job, while emit is open and matches against jobs.

I've wavered on this back and forth before, but I now have a convincing
argument why they *should* be just different aspects of the same
internal queue: events currently contain "failure" information about why
a job was stopped, but command results do not - they both should!  And
this information for both should just come from the job's environment
(just like all other event information) so the job can see what failed
in its post-stop script.


So really, a command is just a special type of event that has the target
job in mind already.  There's a bit of magic on the front of the "start"
command, if the job's while condition isn't true but can be made to be
true, it does so first - rather than erroring out.

(ordinary events don't do this, they only match instances whose while
condition is already true)


Thus we have an internal queue of commands and events; they can be
pending, ie. added to the queue but not yet processes.  This is
desirable to avoid the potential for loops in the code, and remove the
need for deep recursion.

They then can be in progress, once the job(s) are in transition.

And once all job(s) have completed transition, they are completed.


This means that events do not have a history, if your job has "on
control-alt-delete" it is only ever started when control-alt-delete is
actually pressed.  Installing it on a machine which C-A-D was once
pressed in the past does *not* mean it will be started.

If you need the history, you use jobs and "while" - esp. since you need
to know whether the condition is still true.


Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/upstart-devel/attachments/20090912/6e8a7af3/attachment-0001.pgp