Dependencies

[Sean E. Russell]

On Saturday 07 October 2006 15:01, you wrote:
> One of the perils of the "Release Early, Release Often"[0] approach is
> that you'll have people come to you expecting the Moon on a Stick, when
> you're still in the process of figuring out how to get there.

Yeah, as I said to Jerry, I was under the misapprehension that Upstart already 
supported meta-events (IE, an event as defined by a set of events), probably 
because I misinterpreted what the multiple-event listening feature.

> The more complex cases of events with arguments and environment,
> collections of events, waiting for multiple events, etc. are still on
> the drawing board.

Great.  I'm very interested in following this discussion.  As I mentioned, I 
was trying to build a set of Upstart event handlers for Gentoo, which already 
has a sophisticated -- but not event driven -- init system, supporting 
complex and conditional dependencies.  The conversion raises a lot of 
questions about how the same jobs will be done under Upstart, but I'd love to 
at least get to a point where I can boot the system under the new init 
process :-)

> You seem to have some pretty good ideas about how you want things to
> work, please elaborate on them -- the most important part of design is
> having good use cases to start with.

Gladly, but to be honest, they aren't my ideas.  As I said, Gentoo's init 
system is fairly sophisticated, and I'm only raising issues because I'm 
trying to decide how to translate the interrelationships of services.  
However, Gentoo's system does not support (natively, or well) parallel 
service starting, and it isn't event driven -- and I agree that this core 
feature is a significant and powerful paradigm shift.  I suspect that 
Gentoo's system is somewhat complex in implementation, and inefficient, 
although I have no metrics to support that.

I've played with initng as well; I liked it a lot, but it is very easy to 
wedge initng, and this happens a lot on seemingly trivial upgrades.  So now 
I'm back to using Gentoo's vanilla init.

I was also very interested in Apple's launchd... 

But Upstart, through its core design, trumps all of these in potential, and I 
do think that -- if it proves robust -- it *can* eventually replace a number 
of other traditional services (cron being the obvious one).

> Jerry's already pointed out our thoughts on improving events beyond just
> a simple string, and improving the job state machine to fulfil some more
> use cases.  He's been extraordinarly helpful in these ideas, and is just
> a community member like yourself.

I thought that Jerry was suggesting having the scripts handle state.  That's 
not the same as having Upstart have a non-trivial state machine, because the 
scripts are doing all of the work.  Did I misunderstand him?

> Searching is easy:  http://www.google.com/ with
> "site:lists.netsplit.com" as the first keyword.  I don't think I've ever
> used a list server's own search interface.

Thanks.  I'll give that a shot.  Ironically, while I use Google for 
*everything* else, I always forget that it makes a decent list archive 
resource if one can remember the syntax for restricting the search to a 
specific site.

> The list is also indexed/searched by gmane:
> http://dir.gmane.org/gmane.comp.sysutils.upstart.devel

I looked at gmane, but only found the list announcement -- and even now when I 
check it, I only see our current discussion, not the entire archive:

	http://news.gmane.org/gmane.comp.sysutils.upstart.devel

> There is no formalised syntax yet, it's still a rough work in process.
> There's no way to handle multiple event dependencies yet, what syntax do
> you think would work best for this?

It might be useful to have a syntax definition, from a design perspective.  
It'd certainly make a useful reference for users.

If Upstart were going to handle meta-events, and IF* it were going to be a 
simple "act if ALL events have come in", then my reflexive suggestion would 
be to simply extend the current syntax to accept a list of events, rather 
than one:

	start on network/started localfs/started

Order is unimportant.  Start will only be called after BOTH network and 
localfs are started, regardless of what order they came in.

Implementationally, this would probably turn the listener list from a simple 
hash map into a more complex structure.  Although, the init process MUST 
already be tracking process state, so it might be a simple matter of adding 
another event map.

> The reason most things are about sysvinit handling is simply that that's
> been the first priority; being backwards compatible is a *big* important
> first step, and helps us test the ideas without losing the ability to
> revert to sysvinit in case it all goes wrong.

Sure, and sysvinit is Very Common.  It is a good choice for an initial target.  
I'm glad it is detached from the rest of Upstart, though, because there are 
distributions which do not use sysvinit.

> The next step is the one you're taking :)  Please don't stop taking it,
> your help will be invaluable in getting this right.

Well, thanks for working on Upstart.  I know that OS projects are very time 
consuming.

-- 
### SER   
### Deutsch|Esperanto|Francaise|Linux|XML|Java|Ruby|Aikido|Iaido
### http://www.ser1.net  jabber.com:ser  ICQ:83578737 
### GPG: http://www.ser1.net/Security/ser_public.gpg