| === Keybuk [n=scott@wing-commander.netsplit.com] has joined #upstart | ||
| === Keybuk had an interesting idea last night | ||
| AlexExtreme | oh? | 12:38 |
|---|---|---|
| Keybuk | concerning how Status and Job interact | 12:39 |
| Keybuk | so let's say we have a service that uses this: | 12:41 |
| Keybuk | while interface-up until interface-down $IFACE | 12:41 |
| Keybuk | that defines a simple state period between an interface coming up and going down again | 12:41 |
| Keybuk | the state would keep a record of ALL interface-up events | 12:42 |
| Keybuk | and ALL of them would have to be cancelled before the interface could go down | 12:42 |
| Keybuk | ie. that defines a service running while any network interface is up | 12:42 |
| Keybuk | a simple modification: | 12:44 |
| Keybuk | while interface-up until interface-down $IFACE | 12:44 |
| Keybuk | instance | 12:44 |
| Keybuk | this job behaves differently; now each time an interface comes up, a new instance of the job is spawned, and that instance runs until the interface it was spawned for goes down | 12:44 |
| Keybuk | since states can be canned (and for other reasons) you'll want to be able to restrict which interfaces this is true for | 12:48 |
| Keybuk | so you'd allow something like | 12:48 |
| Keybuk | state interface-is-up | 12:48 |
| Keybuk | while interface-up until interface-down $IFACE | 12:49 |
| Keybuk | end state | 12:49 |
| Keybuk | -- | 12:49 |
| Keybuk | while interface-is-up ~lo | 12:49 |
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| Keybuk | the other change to make is to Event | 12:56 |
| Keybuk | I'm going to get rid of different positional and name-based variables | 12:56 |
| Keybuk | instead it's going to have just name-based ones, but in a particular order | 12:56 |
| Keybuk | so an event might be | 12:56 |
| Keybuk | stopping JOB=apache RESULT=failed FAILED_PROCESS=main | 12:57 |
| Keybuk | and for matching in job definitions, you can omit the names in order until you give the first name | 12:57 |
| Keybuk | but the scripts won't receive any arguments, just them as environment variables | 12:57 |
| AlexExtreme | so we won't be able do have events like "interface-up eth0", instead it would be "interface up IFACE=eth0" ? | 12:58 |
| Keybuk | you cam omit the name provided eth0 is the first event in the list | 01:00 |
| Keybuk | (which it would be) | 01:00 |
| Keybuk | in effect, they become like python method calls | 01:10 |
| Keybuk | this makes figuring out what to pass to the jobs MUCH easier ;) | 01:13 |
| Keybuk | since there's no worry about which gets $1, $2, etc. they all get arguments by name! | 01:13 |
| Keybuk | likewise | 01:13 |
| Keybuk | interface-up until interface-down $IFACE | 01:14 |
| Keybuk | is more obvious than | 01:14 |
| Keybuk | interface-up until interface-down $1 | 01:14 |
| AlexExtreme | yes | 01:14 |
| ion_ | Sounds good. | 01:18 |
| Keybuk | ion_: does the state/instance stuff make sense? | 01:24 |
| ion_ | In what situations would counting the number of up events and waiting for the number of down events to match is necessary? | 01:26 |
| ion_ | How about adding a new state to a running system it would have no knowledge of recently emitted events it needs to track. | 01:28 |
| ion_ | Oh, i misunderstood the intent. Ignore the In what situations... line. | 01:29 |
| Keybuk | not so much counting, but matching pairs | 01:29 |
| Keybuk | and keeping track of which interfaces are still up | 01:29 |
| ion_ | Yeah, i realized that. :-) | 01:29 |
| Keybuk | it makes a lot of sense to have a service running while at least one network interface is up | 01:29 |
| ion_ | Regarding the interface-is-up alias, id like the syntax to be more like: while interface-is-up IFACE=~lo until interface-down $IFACE, where the first part would be a fnmatch-ish match against the variable and the second part would match against the stored value. | 01:32 |
| ion_ | Something like... | 01:32 |
| ion_ | while interface-is-up IFACE=* until interface-down $IFACE | 01:33 |
| ion_ | would be equivalent to | 01:33 |
| ion_ | while interface-is-up IFACE until interface-down $IFACE | 01:33 |
| ion_ | The difference to | 01:33 |
| ion_ | while interface-is-up IFACE until interface-down IFACE | 01:33 |
| ion_ | would be that any interface-is-up ... interface-down pair would match, since the IFACE value isnt compared to anything. | 01:34 |
| ion_ | interface-down $IFACE would point to the value implicitly stored by interface-is-up IFACE | 01:34 |
| Keybuk | I'm not sure I follow | 01:36 |
| Keybuk | you mean interface-up (an event) not interface-is-up? | 01:37 |
| ion_ | Ah, sorry. I meant interface-up | 01:37 |
| Keybuk | ah, you mean name the variables on the left you intend to use on the right? | 01:37 |
| Keybuk | interface-up IFACE until interface-down $IFACE | 01:37 |
| Keybuk | not | 01:37 |
| ion_ | Yes. | 01:37 |
| ion_ | That would allow more complex matches, such as: | 01:37 |
| Keybuk | interface-up until interface-down $IFACE | 01:37 |
| ion_ | while interface-up ADDR=10.0.0.* IFACE until interface-down $IFACE | 01:37 |
| Keybuk | I don't see why the IFACE bit is needed? | 01:38 |
| Keybuk | that would work | 01:38 |
| Keybuk | while interface-up ADDR=10.0.0.* until interface-down $IFACE | 01:38 |
| Keybuk | ? | 01:38 |
| ion_ | True. Just store all the variables by default, so that any of them could be matched against in the until part. | 01:39 |
| ion_ | So IFACE would need to be mentioned in the first part *only* if its matched against something. | 01:39 |
| ion_ | while interface-up IFACE=~lo until interface-down $IFACE | 01:40 |
| ion_ | while interface-up until interface-down $IFACE | 01:40 |
| ion_ | while interface-up ADDR=10.0.0.* until interface-down $IFACE | 01:40 |
| ion_ | for example | 01:40 |
| ion_ | Perhaps IFACE!=lo instead? | 01:41 |
| Keybuk | yeah, either works doesn't it | 01:41 |
| Keybuk | actually, I prefer != | 01:41 |
| ion_ | ADDR!=10.* | 01:41 |
| ion_ | Anyway, that would remove the need to define a named alias just to be able to give patterns. Of course, aliases might be very useful for other purposes. | 01:43 |
| Keybuk | the named alias would be for complex things like "user-can-login" | 01:43 |
| ion_ | Yeah | 01:43 |
| Keybuk | if state allows spawning like this, then we could have structures like for loops in there | 01:44 |
| Keybuk | for PATH in `getmntent -fD` path-mounted $PATH until path-unmounted $PATH | 01:45 |
| Keybuk | :p | 01:45 |
| ion_ | NEat. | 01:47 |
| ion_ | Perhaps make it block-like | 01:48 |
| ion_ | for PATH in $(getmntent -fD) | 01:48 |
| ion_ | while path-mounted $PATH until path-unmounted $PATH | 01:48 |
| ion_ | end for | 01:48 |
| Keybuk | that could work too | 01:49 |
| === phoenix24 [n=phoenix2@59.176.23.106] has joined #upstart | ||
| ion_ | Another idea that accomplishes the same thing a bit differently: assign the output of getmntent -fD to an array variable, and do a single while expression that matches PATH to the array. | 01:50 |
| ion_ | Also, an interface-up event might have multiple ADDR variables. It should be possible to match against any of them, or all of them. | 01:54 |
| Keybuk | how would you define/match that? | 01:54 |
| ion_ | interface-up any(ADDR or(ADDR=127.* ADDR=::1)), where any would loop through ADDR variables and return true if any of the expressions return true. That syntax is ugly, though, but it can be improved. :-) | 01:58 |
| ion_ | (any? ADDR (or ((match? ADDR "127.*") (match? ADDR "::1")))) ;-) | 02:00 |
| ion_ | (all? ADDR (match? ADDR "*:*")) IPv6-only interface | 02:01 |
| ion_ | Just like for foo in ADDR, do something with foo, but simplified to for ADDR, do something with ADDR, where inside the loop, ADDR is the value currently being iterated. | 02:05 |
| ion_ | (blah ((mountpoints "getmntent -fD")) (any? mountpoints (eq? mountpoints PATH))) | 02:13 |
| ion_ | Im definitely not saying thats what the syntax should be, just formulating ideas about how things could be matched. | 02:15 |
| Keybuk | I've found lisp/scheme-like syntax easier to work things out in too | 02:22 |
| Keybuk | simply because it's already in the same shape as the necessary syntax tree to evaluate it | 02:22 |
| Keybuk | rather than the latter | 02:23 |
| Keybuk | uh, rather than the humanish way of putting it | 02:24 |
| Keybuk | what does the mountpoints thing do? | 02:24 |
| ion_ | Um, just assigns the output of the command to an array variable. Then the arrays compared to the PATH variable. | 02:27 |
| ion_ | mountpoints.any? {|dir| env[:PATH] == dir } # Ruby syntax :-) | 02:27 |
| === Amaranth_ [n=travis@ubuntu/member/Amaranth] has joined #upstart | ||
| === mbiebl [n=michael@p549cdf03.dip.t-dialin.net] has joined #upstart | ||
| === penguin42 [n=dg@tu006.demon.co.uk] has joined #upstart | ||
| === penguin42 yawns | ||
| penguin42 | I fancy adding a --host to the reboot/shutdown/halt utilities to check that the host you specify is the one you think you are trying to shut down | 03:56 |
| penguin42 | I was also considering requiring it if it's run from a tty - anyone have strong views? | 03:57 |
| Keybuk | heh | 03:58 |
| Keybuk | interesting patch ;) | 03:58 |
| penguin42 | one too many halts of the wrong machine :-) | 03:58 |
| penguin42 | I can't think of anything shorter than --host that would work on all of reboot/shutdown/halt | 04:00 |
| Keybuk | you'd need to give the hostname | 04:00 |
| Keybuk | shutdown -h quest | 04:00 |
| penguin42 | yeh exactly | 04:00 |
| penguin42 | except shutdown already has a -h for example | 04:01 |
| === penguin42 will put something together - where is a good place to send the patch? | ||
| AlexExtreme | the bug tracker at launchpad probably | 04:07 |
| penguin42 | oh ok, I hadn't realised people used launchpad for patch stuff as well | 04:07 |
| Keybuk | penguin42: upstart-devel@lists.ubuntu.com | 04:09 |
| Keybuk | or launchpad, yeah | 04:09 |
| Keybuk | if you prefer, make a bzr branch of upstart and upload your branch to LP | 04:10 |
| penguin42 | ok, I'll probably launchpad it since I've already got a launchpad account; probably just a patch for the moment unless I fancy figuring out the branch stuff | 04:11 |
| Keybuk | :) | 04:12 |
| === AlexExtreme loves bzr :P | ||
| Keybuk | yeah, it's not terrible | 04:20 |
| penguin42 | is bzr yet-another-source-code-control thing? | 04:20 |
| AlexExtreme | yep | 04:22 |
| penguin42 | Why does 'reboot' scan only ide discs to power them down? | 04:27 |
| Keybuk | penguin42: it doesn't even need to do that | 04:29 |
| Keybuk | originally it was because the code was copied from sysvinit, and only ide disks existed then | 04:29 |
| AlexExtreme | now the kernel automatically does it | 04:30 |
| penguin42 | ah ok | 04:30 |
| penguin42 | reboot does seem to have a small random selection of clean up things in it | 04:31 |
| Keybuk | yeah | 04:31 |
| Keybuk | our goal is to eliminate both | 04:31 |
| penguin42 | anyone good with man macros; .BR -m, --host \fI HOST doesn't seem to want to render a space before HOST | 05:37 |
| Keybuk | I tend to just quote things | 05:38 |
| penguin42 | that's still getting me -m,--hostHOST | 05:41 |
| Keybuk | .BR -m ", " --host \fIHOST | 05:43 |
| Keybuk | ? | 05:43 |
| penguin42 | yeh but it's the space after '--host' I can't get to happen | 05:44 |
| penguin42 | let me try a " " | 05:44 |
| Keybuk | "--host " ? :p | 05:44 |
| penguin42 | yeh that's done it | 05:44 |
| penguin42 | typesetter being too smart for its own good :-) | 05:45 |
| penguin42 | ok, #117215 | 06:19 |
| === Keybuk [n=scott@wing-commander.netsplit.com] has joined #upstart | ||
| ion_ | I learned a new word from Futurama: oughtnt :-D | 12:15 |
| cortana | i learned "unpossible".... i don't think that's a real word tho | 12:17 |
| Keybuk | heh | 12:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!