| _ion | keybuk: In http://upstart.ubuntu.com/wiki/ComplexEventConfig, it is said that and/or has higher precedence than until. Wouldn't that mean that 'from foo until frodo or from bar until bilbo' is equal to 'from foo until (frodo or (from bar until bilbo))'? | 12:34 |
|---|---|---|
| Keybuk | _ion: I dunno, I'm a bit fuzzy about how that works :p | 12:34 |
| Keybuk | I wrote what seemed to be right, but I think it's wrong | 12:34 |
| Keybuk | that spec's still in drafting until I'm sure | 12:35 |
| Keybuk | when it comes to precedence, I just remember that "division and multiplication beat subtraction and addition, for everything else, use parens" | 12:37 |
| _ion | I started writing a parser based on the draft using racc (a yacc-ish parser generator for ruby) and i noticed '(from foo until (frodo or (from bar until bilbo)))' in debug output, that's why i asked. :-) Of course i realize it's still a preliminary document. | 12:39 |
| _ion | Btw, have you considered using bison for parsing the config files? It would make defining and modifying the grammar quite easy, especially with the more complex rules. | 12:40 |
| _ion | (Hmm, have i already asked this before?) | 12:41 |
| Keybuk | I originally used bison/yacc | 12:42 |
| Keybuk | and the code it generated was huge, and difficult to get it to work right | 12:42 |
| Keybuk | it was easier to just write the parser by hand | 12:42 |
| Keybuk | it's not that large after all (just the cfg_next_token function, really) | 12:42 |
| _ion | Ok. | 12:42 |
| === gbutler69 [n=gbutler6@pseudo220.jewels.com] has joined #upstart | ||
| gbutler69 | On Ubuntu 6.10 can one create a config that will cause Upstart to start/stop in.telnetd as needed (instead of running inetd/xinetd)? | 12:45 |
| gbutler69 | Anyone? | 12:46 |
| Keybuk | not in 6.10, no; the upstart version there has no facility to replace inetd | 12:46 |
| === Seveas [n=seveas@ubuntu/member/seveas] has joined #upstart | ||
| _ion | racc is quite nice, there's a backend class (written in C for speed) in the ruby standard library; the generated parser files don't contain extra crud, they just subclass Racc::Parser. | 12:49 |
| _ion | I'll try to get the graphviz thingy done some day. :-) | 12:51 |
| gbutler69 | KeyBuk: Thanks....that's what I was looking for? Out of curiosity, when will this support exist (planned)? | 12:52 |
| Keybuk | gbutler69: ubuntu 7.10, I would guess | 12:52 |
| Keybuk | it's not planned for upstart 0.3, which is aimed for Ubuntu 7.04 | 12:57 |
| gbutler69 | KeyBuk: OK, thanks.... | 01:01 |
| Keybuk | that's not to say it won't happen, if someone codes it | 01:02 |
| Keybuk | of course | 01:02 |
| gbutler69 | That was my next question.... | 01:02 |
| gbutler69 | Need a volunteer to work on that? | 01:02 |
| Keybuk | patches are always welcome | 01:03 |
| gbutler69 | OK...I think I'll start taking a look at it....probably won't get to it much until after the Holiday though....:) | 01:03 |
| Keybuk | I'm hoping to get some upstart hacking done over the holiday | 01:04 |
| Keybuk | will be my main chance to do it | 01:05 |
| gbutler69 | Should "upstartd" just listen for connections in place of "inetd/xinetd" or should replacement "indetd" be create that is part of the "upstart" package and it triggers the "connection received on port XX" events? | 01:07 |
| gbutler69 | Any vision for this yet? | 01:09 |
| Keybuk | (...vague gut feeling: pid #1 shouldn't have net connections :p) | 01:15 |
| === gbutler [n=gbutler@69-168-169-204.clvdoh.adelphia.net] has joined #upstart | ||
| === j_ack_ [n=rudi@p508D9348.dip0.t-ipconnect.de] has joined #upstart | ||
| gbutler | If I want to work on the "replace inetd functionality" for upstart, where should I begin documenting/proposing the how, why, and what? | 03:20 |
| gbutler | I'd like to start work on the spec for Upstart handling "inetd" events/traffic. | 03:30 |
| gbutler | I can't seem to figure out the "Upstart Wiki" thing though. How does one go about editing/adding specifications to it? | 03:31 |
| _ion | The wiki and the mailing list are good starting points. | 03:31 |
| wasabi_ | I'm not totally sure it's worth replacing inetd. | 04:09 |
| wasabi_ | I mean, honestly, inetd works fine. | 04:09 |
| wasabi_ | Or xinetd, whichever one you want. | 04:09 |
| wasabi_ | I doubt any of us want to tackle that complete code base (again) | 04:09 |
| wasabi_ | Maybe scott just can't wait, though. =) | 04:10 |
| gbutler | wasabi_: Yes, I agree. I created a "lauchpad" entry and a spec placeholder. For the "Rationale" I put a lot of questions which basically all equate to, "Do we REALLY want upstart to replace inetd/xinetd?" | 04:13 |
| === maro [n=mark@0x55511dab.adsl.cybercity.dk] has joined #upstart | ||
| gbutler | I figure it enough "Rationale" can be found, then maybe it's worth doing....but, as I sat trying to think of reasons, I couldn't come up with anything other than, "We'd like upstart to be the central place for Job Control". | 04:14 |
| === gbutler [n=gbutler@69-168-169-204.clvdoh.adelphia.net] has left #upstart [] | ||
| === Amaranth [n=travis@unaffiliated/amaranth] has joined #upstart | ||
| === peeps [n=peeps@cpe-70-112-25-110.austin.res.rr.com] has joined #upstart | ||
| === psibox [n=dreger@smart.physik.fu-berlin.de] has joined #upstart | ||
| === ced_ [n=ced@n220246132035.netvigator.com] has joined #upstart | ||
| ced_ | hey | 09:50 |
| ced_ | where can i find the upstart manual? man upstart does not return anything | 09:58 |
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| === Keybuk [n=scott@syndicate.netsplit.com] has joined #upstart | ||
| === j_ack [n=rudi@p508D9359.dip0.t-ipconnect.de] has joined #upstart | ||
| AlexExtreme | hmm | 05:22 |
| AlexExtreme | IMO inetd functionality shouldn't be added | 05:22 |
| _ion | Why not? | 05:22 |
| AlexExtreme | it's a bit dangerous to have process 1 handling internet connections - if there was security flaw, it would be easy to bring down the system | 05:22 |
| AlexExtreme | correct me if i'm wrong, though | 05:23 |
| _ion | Since when is process 1 going to handle network connections? | 05:23 |
| AlexExtreme | if inetd functionality is added... | 05:23 |
| _ion | It's not as if it's going to be added to /sbin/init :-) | 05:23 |
| _ion | init just launches stuff based on events. | 05:23 |
| AlexExtreme | hmm | 05:23 |
| AlexExtreme | :P | 05:23 |
| AlexExtreme | <Keybuk> +(...vague gut feeling: pid #1 shouldn't have net connections :p) << Keybuk said the same ;) | 05:24 |
| _ion | I believe everybody has that feeling. :-) | 05:24 |
| === theCore [n=alex@ubuntu/member/theCore] has joined #upstart | ||
| === juergbi [n=juerg@80-219-26-249.dclient.hispeed.ch] has joined #upstart | ||
| _ion | keybuk: 'on foo and bar' will upstart accumulate received events that match, and change the goal to 'start' when foo_received & bar_received == true? Will the accumulation of those events then be stopped until the goal is 'stop' again? | 09:31 |
| Keybuk | yes to the first part | 09:32 |
| Keybuk | when "foo" occurs, that node in the graph will be TRUE | 09:33 |
| Keybuk | and when "bar" occurs, that node in the graph will also be TRUE | 09:33 |
| Keybuk | the "and" parent node of both is TRUE only once both children are TRUE | 09:33 |
| Keybuk | I'm not sure what the next bit suggests? | 09:33 |
| _ion | I mean: | 09:34 |
| _ion | on foo and bar | 09:34 |
| _ion | stop on quux | 09:34 |
| _ion | Let's 'foo', 'bar' are received, and then 'quux' is received. | 09:34 |
| _ion | +say | 09:34 |
| Keybuk | right | 09:34 |
| Keybuk | the goal will be stop, job will be stopped | 09:34 |
| Keybuk | the complex tree will be TRUE, but won't be evaluated, so won't cause the goal to change yet | 09:35 |
| _ion | What i meant with the second question is that after the goal is set to stop, the state of 'on foo and bar' should be false again, until foo and bar are received again, right? | 09:35 |
| Keybuk | no | 09:37 |
| Keybuk | the state is TRUE | 09:37 |
| Keybuk | both events have occurred, as prescribed | 09:37 |
| _ion | All right. | 09:37 |
| Keybuk | to explain why | 09:37 |
| Keybuk | imagine foo is "fhs-filesystem-up" | 09:37 |
| Keybuk | and bar is "network-up" | 09:37 |
| Keybuk | and quux is "network-down" | 09:37 |
| Keybuk | if the job is stopped when the network is down, you don't want to have to wait until the filesystem goes down and up as well | 09:38 |
| Keybuk | you just want it restarted when the network comes up | 09:38 |
| Keybuk | the way to cause the tree to be reset to FALSE is to use "untilo" | 09:39 |
| Keybuk | (foo and bar) until quux | 09:39 |
| Keybuk | now, when quux occurs, the other side of the tree is explicitly set to false | 09:39 |
| Keybuk | foo and bar both have to occur again | 09:39 |
| _ion | So the boolean value of 'on fhs-filesystem-up and network-up' will be calculated when (and only when) either 'fhs-filesystem-up' or 'network-up' is received, and if it amounts to TRUE, the goal will be changed to start? | 09:40 |
| Keybuk | yes | 09:41 |
| _ion | Ok, now i understand it. :-) | 09:41 |
| Keybuk | the tree is evaluated upwards each time a node is changed | 09:41 |
| _ion | Is 'on fhs-filesystem-up and network-up' equivalent to 'start on fhs-filesystem-up and network-up'? | 09:44 |
| Keybuk | err? | 09:45 |
| Keybuk | no | 09:45 |
| === che [n=bleh@redhat/che] has joined #upstart | ||
| _ion | Sorry, i don't see the difference. I've probably misinterpreted or misread something from the complex-event-config doc. | 09:49 |
| Keybuk | that would match an fhs-filesystem-up event with the arguments "and" & "network-up" ? | 09:49 |
| _ion | Hmm. | 09:49 |
| _ion | How to match something with the argument 'and' from an 'on' or 'until' expression? :-) | 09:50 |
| Keybuk | what do you want to match | 09:51 |
| Keybuk | describe the state | 09:51 |
| _ion | That was just a hypothetical example. What i'm really thinking is making 'and' a reserved word something that can't be matched and changing the 'start on' expression to what is defined as 'on' in complex-event-config. Perhaps make it possible to match a reserved word as follows: start on foo "and" bar | 09:56 |
| Keybuk | the trouble is that the complex expression also defines when things stop | 09:57 |
| Keybuk | not just when they start | 09:57 |
| Keybuk | so "start on network-up until network-down" makes no sense | 09:57 |
| Keybuk | which is why we decided it was separate from start on/stop on | 09:57 |
| _ion | I thought it was "from network-up until network-down" | 09:57 |
| Keybuk | like I said, it makes no sense to allow that for start | 09:57 |
| Keybuk | from/on are just syntactic sugar | 09:57 |
| Keybuk | network-up until network-down | 09:58 |
| Keybuk | (where until is the joining operator) | 09:58 |
| Keybuk | network-up until network-down and fhs-up until fhs-down | 09:58 |
| Keybuk | block-device-added and network-up until network-down | 09:58 |
| Keybuk | ^ block device added while there's a network | 09:58 |
| Keybuk | the complex config is intended to be a discreet thing to start on/stop on | 09:59 |
| Keybuk | with the latter just "easy options" | 09:59 |
| _ion | Ok, i see. | 10:00 |
| Keybuk | maybe it's not clear in the spec | 10:00 |
| Keybuk | or maybe it just doesn't make sense for it to behave this way | 10:00 |
| Keybuk | the problem we wanted to avoid was this: | 10:01 |
| Keybuk | start on network-up and fhs-filesystem-up | 10:01 |
| Keybuk | stop on network-down and fhs-filesystem-down | 10:01 |
| _ion | So basically 'on' and 'from' are just ignored, but they are necessary in the beginning of a line? | 10:01 |
| Keybuk | on startup, both network-up and fhs-filesystem-up happen | 10:01 |
| Keybuk | then the network goes down, so network-down happens | 10:01 |
| Keybuk | (err, that latter should be "stop on network-down OR fhs-filesystem-down", sorry) | 10:02 |
| Keybuk | so the job stops | 10:02 |
| Keybuk | but the "network-up and fhs-filesystem-up" bit is still TRUE (those events have both happened) | 10:02 |
| Keybuk | so if you get fhs-filesystem-down followed by fhs-filesystem-up | 10:03 |
| Keybuk | the job will get started, despite the network not being up | 10:03 |
| Keybuk | that's what "until" is for | 10:03 |
| Keybuk | "network-up until network-down" explicitly states that the fact network-up has happened is forgotten once network-down happens | 10:03 |
| Keybuk | and once you have that, you can't easily express that in terms of start or stop | 10:04 |
| Keybuk | because it says both | 10:04 |
| _ion | Thanks for explaining. | 10:11 |
| Keybuk | does that make sense? | 10:11 |
| Keybuk | is it crack? | 10:11 |
| _ion | I agree with almost everything, only the syntax could be a bit cleaner IMHO. I'd replace 'on' and 'from' with 'SOMESTANZA <expr>' where expr is a combination of '<event>', '<expr> and <expr>', '<expr> or <expr>', '<expr> until <expr>', 'with <job>'. Also 'with <job>' wouldn't be a valid line without the 'SOMESTANZA' in front of it. | 10:22 |
| Keybuk | ok | 10:24 |
| Keybuk | what's a suitable SOMESTANZA? | 10:24 |
| _ion | Still thinking of that. :-) | 10:25 |
| _ion | It should be short and self-descripting. | 10:25 |
| Keybuk | the language for that syntax has caused us issues :) e.g. "and" behaves more an intersection | 10:26 |
| Keybuk | where as "A until B and C until D" in English implies a union | 10:26 |
| Keybuk | and the English "A until B or C until D" implies a difference :) | 10:27 |
| _ion | Actually, 'on' *is* quite good, but IMHO it should not be allowed inside <expr>, and 'from' being an alias for it causes confusion. | 10:28 |
| _ion | I would change | 10:29 |
| _ion | from network-up until network-down | 10:29 |
| _ion | and from fhs-mounted until fhs-unmounted | 10:29 |
| _ion | to: | 10:29 |
| _ion | on network-up until network-down \ | 10:30 |
| _ion | and fhs-mounted until fhs-unmounted | 10:30 |
| _ion | Or instead of using a \ put the expression (after 'or') in parenthesis. | 10:30 |
| _ion | I mean after 'on' | 10:31 |
| Keybuk | is 'from' not better than 'on' ? | 10:31 |
| _ion | I think there should only be one stanza, no aliases. I'm not sure whether it should be 'on' either. The syntax should allow any of the following: | 10:35 |
| _ion | FOO some-event | 10:35 |
| _ion | FOO network-up until network-down and fhs-mounted until fhs-unmounted | 10:35 |
| _ion | FOO with apache or with httpd | 10:35 |
| Keybuk | and get rid of "stop on" entirely? | 10:35 |
| _ion | "start on <event>" and "stop on <event>" would still be there for simple event config, but "FOO <expression>" would be added for complex event config. | 10:36 |
| _ion | line : 'start on' EVENT | 'stop on' EVENT | 'FOO' expression | ... ; | 10:39 |
| _ion | expression : EVENT | expression 'and' expression | expression 'or' expression | expression 'until' expression | with JOB | '(' expression ')' ; | 10:39 |
| _ion | Or something like that. | 10:39 |
| Keybuk | ok | 10:39 |
| Keybuk | that's pretty much what I was going for :) | 10:39 |
| Keybuk | just gotta pick a FOO | 10:40 |
| Keybuk | and get rid of the on/from bit | 10:40 |
| _ion | Whoops, s/with/'with'/ | 10:40 |
| Keybuk | the reason for allowing multiple 'on's was to allow: | 10:42 |
| Keybuk | on foo and | 10:42 |
| Keybuk | on bar | 10:42 |
| Keybuk | without requiring | 10:42 |
| Keybuk | on foo and \ | 10:42 |
| Keybuk | on bar | 10:42 |
| Keybuk | (ie. \ avoidance) | 10:42 |
| _ion | Perhaps ignore a newline after and/or/until/with? | 10:48 |
| _ion | FOO network-up until network-down and | 10:48 |
| _ion | fhs-mounted until fhs-unmounted | 10:48 |
| Keybuk | perhaps | 10:55 |
| === j_ack [n=rudi@p508D9359.dip0.t-ipconnect.de] has joined #upstart | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!