Upstart 1.0 Design discussion

[Casey Dahlin]

On 09/11/2009 10:13 PM, Scott James Remnant wrote:
> 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.
>

It was a lot clearer this time :)

>
> 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 ;-)
>

meh. 2 minutes with sed if we ever find a word we like :).

> 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".
>

You use the term "levels." That term draws from electrical engineering, 
when talking about logic graphs (that look a lot like the line you drew 
above :). From there we'd get the terms "high," "low," "rising," and 
"falling." That's a bit too vocabulary-intensive for your style I think 
but its a start :) If we wanted to improve iteratively from there I'd 
probably recommend "up" and "down" rather than "high" and "low." These 
are general enough to work for non-jobs, but their roots are more in 
sysadmin-land than academia, which is good for our userbase.

> 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.
>
[Snip]
>
>
> 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
>

This comes off much less radical sounding than it did on IRC :)

I'll save my follow-up for LPC. It may take some intense explanation. 
The crux of it is that we might be able to implement a few more stanzas 
that don't outwardly make sense, and, with the addition of being able to 
#include other files within job definitions, be able to eliminate large 
quantities of upstart's code in favor of a job state machine described 
in job definition syntax. Freaky huh?

--CJD