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 -- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
