Upstart 1.0 Design discussion

[Scott James Remnant]

On Fri, 2009-09-11 at 17:03 -0400, Casey Dahlin wrote:

> I've had some suggestions for the Upstart 1.0 design which came up
> when I spoke to Scott on IRC the other day. I would like to post them
> here, but for continuity's sake, I figured I'd simply post the 1.0
> design as Scott described it (and I understood it), and then work from
> there.
> 
I'll try and describe things in my own words, since the behaviour is
about right but not how I think that it'll work under the hood.


Upstart will have, as it has now, a primary first-class object that it
tracks.  I tend towards dislike calling these "states" since these
things themselves have states; Casey suggested "conditions" but that has
implications I don't like.

Upstart internally calls them jobs.  Let's just call them that, because
I doubt that the code will ever call them anything but ;-)

Jobs can represent conditions, they can represent states, they can
represent services and they can represent tasks.  They may have attached
processes, but they also may not.

	(If we use "services" and "tasks" to only ever refer
	 to jobs with attached processes, then I think it's
	 not confusing.)


Jobs have two principal properties: their state, and their goal.  But I
think that this is an implementation detail.  From a theoretical
standpoint, we should instead say that Jobs have two Levels.

Transition between these levels is not necessarily instantaneous, Jobs
may be in transition from the ground state to the active state.  Here's
a picture.


		   ________             started
		  /        \
		 /          \
	________/ |        | \________  stopped
	          |        |
	    starting      stopping


I strongly dislike these terms.  I actually spent almost a day this week
tracking down a bug in Ubuntu's upstart-native boot caused by using
"start on starting udev" when I meant "start on started udev".

It's also worth pointing out that in practice, these labels should be at
the transition points and not apply to the transitions as a whole.  But
meh, theory vs. implementation.

What's important is that there are actually four states.  The two states
representing the two levels which are "stable" states (given no further
input, we tend to stay in them), and two states representing the
transition between levels which are "unstable" states (they end
themselves).


As well as the two obvious conditions as whether a job is at the higher
level or the lower level, useful for depending on the job and being a
dependency of the job respectively, there's another interesting
condition of whether this job *should* be at the higher level:

                +----------+
	        |  ________|
	        | /        \
	        |/          \
	________/            \________

There's mathematically the opposite as well, but I can't think of a use
for that one ;)


The condition of whether a job should be at the higher level is
important, it's the one that Upstart changes itself.  We've used the
planned "while" stanza for this one.

"while" can reference any other job.  You can perform boolean logic with
"and", "or" and "not" and you can group.

	while (foo and bar) or not baz

The job's should state is coupled do this; when this condition is true,
the job should be started and the state transition will begin.


Now, you should be asking which of the job's conditions this matches.  I
think this matches the upper level, because that's the most _common_ use
case:

	while apache

should mean while apache is running, not while apache should be running
or while apache is not not running.

However, "while apache is not not running" is important since it's used
for insertion dependencies.  A proposed stanza for this is "before", I
just don't like it ;)

	before apache

Another way might be just to sub-job this:

	while apache start

or something.  Then we can just add another for the "should" case if we
want to match on that.


This is all well and good for automatic jobs, but we also want jobs that
still respond to good old "events".  "while" ensures an instance exists,
but if the job uses an "on" stanza that instance is not automatically
started.

	on some-event

You can use multiple "on" stanzas, any one will start that instance.


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.


I forsee being able to nest any level of sub-jobs like this; for
example:

	samba nmbd post-stop


This assumes that events are generated by the state transitions in jobs,
and are named exactly for them and carry the same environment.  I think
that's perfect.

I also think we still need stand-alone events for things like
"control-alt-delete" and "reboot", etc.


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/29a17a89/attachment-0001.pgp