Keybuk | hurrah | 14:06 |
---|---|---|
Keybuk | after 4 hours of fiddling, I'm now back to being able to make a change :p | 14:06 |
Keybuk | http://bazaar.launchpad.net/~keybuk/upstart/trunk/revision/scott%40netsplit.com-20080411134155-1ormw1ojnkh5thqb?start_revid=scott%40netsplit.com-20080411134155-1ormw1ojnkh5thqb | 14:42 |
Keybuk | \o/ | 14:42 |
Keybuk | and with the following revision, we now support respawn and task :) | 14:59 |
Keybuk | task | 14:59 |
Keybuk | exec /some/script | 14:59 |
Keybuk | respawn | 14:59 |
Keybuk | will repeat /some/script until it exits with zero :) | 14:59 |
ion_ | keybuk: Nice | 17:02 |
Keybuk | My main blocker at the moment is deciding whether or not to export the difference between Jobs and Instances over D-Bus | 17:38 |
Keybuk | and if not, which way to err | 17:38 |
Keybuk | ie. | 17:46 |
Keybuk | should it have a D-Bus object per job | 17:46 |
Keybuk | should it have a D-Bus object per instance | 17:46 |
Keybuk | or should it have D-Bus objects for both? | 17:46 |
Keybuk | per job would mean you had .../jobs/getty with Start() and Stop() methods, and methods to probe for instance and process information | 17:47 |
Keybuk | per instance would mean you had .../jobs/getty-tty1 with a Stop() method; and a Start(name) method on the upstart object | 17:48 |
Keybuk | both would mean you had .../jobs/getty with Start() and StopAll() methods, then .../jobs/getty/tty1 with a Stop() method and methods to probe process information | 17:48 |
ion_ | I’d lean towards the latter, and .../jobs/getty would provide a method to find a list of .../jobs/getty-tty1 etc. | 17:48 |
ion_ | My thinking tends to favor object-orientation. | 17:49 |
Keybuk | the only real problem with the latter I guess is the overhead in terms of D-Bus objects | 17:50 |
Keybuk | Job.Start(Array of String env) | 17:50 |
Keybuk | job.GetInstance(Array of String env) | 17:50 |
Keybuk | job.GetInstanceByName(String name) | 17:50 |
Keybuk | something like that? | 17:50 |
ion_ | But is that overhead really that big? | 17:51 |
Keybuk | maybe not I guess | 17:51 |
Keybuk | Job.Start(Array of String env) => (Object Path instance) | 17:51 |
Keybuk | Job.GetInstanceByName(String name) | 17:52 |
Keybuk | Job.GetInstanceByEnv(Array of String env) | 17:52 |
Keybuk | (all => instance) | 17:52 |
Keybuk | Job.StopAll(Array of String env) | 17:52 |
Keybuk | Instance.Stop(Array of String env) | 17:52 |
Keybuk | Instance.Restart() | 17:52 |
ion_ | Looks nice. | 17:53 |
Keybuk | Manager.GetJobByName(String name) | 17:53 |
Keybuk | I guess that'd mean I could throw away instance ids :p | 18:15 |
Keybuk | UPSTART_JOB=getty | 18:15 |
Keybuk | UPSTART_INSTANCE=tty1 | 18:15 |
Keybuk | would be enough :p | 18:15 |
ion_ | How would that go currently? | 18:15 |
Keybuk | right how you'd have | 18:16 |
Keybuk | UPSTART_JOB=getty | 18:16 |
Keybuk | UPSTART_JOB_ID=3721 | 18:16 |
Keybuk | where initctl would only use the latter | 18:16 |
Keybuk | if I dropped ids, initctl would use both | 18:16 |
Keybuk | Manager.GetJobByName($UPSTART_JOB).GetInstanceByName($UPSTART_INSTANCE).Stop() :p | 18:16 |
ion_ | Nice | 18:17 |
Keybuk | "start" would become an error in a job | 18:17 |
Keybuk | with "restart" being the right command | 18:18 |
Keybuk | ie. | 18:18 |
Keybuk | pre-stop script | 18:18 |
Keybuk | [ ... ] || restart | 18:18 |
Keybuk | end script | 18:18 |
Keybuk | ? | 18:18 |
Keybuk | hmm | 18:18 |
Keybuk | maybe they should still be different | 18:18 |
Keybuk | start returns you to start without killing | 18:18 |
Keybuk | restart would kill, but return you back to start again | 18:18 |
ion_ | Any use cases? | 18:20 |
Keybuk | just thinking of things being common senes | 18:21 |
Keybuk | there's a few obvious ones | 18:21 |
Keybuk | stop on stopping some-other-job | 18:21 |
Keybuk | pre-stop script | 18:21 |
Keybuk | if can-carry-on-with-it-but-need-restart; then | 18:21 |
Keybuk | restart | 18:21 |
Keybuk | fi | 18:21 |
Keybuk | if can-ignore-it-safely; then | 18:22 |
Keybuk | start | 18:22 |
Keybuk | fi | 18:22 |
Keybuk | end script | 18:22 |
ion_ | Perhaps start should be named otherwise to avoid confusion, though. | 18:22 |
Keybuk | such as? | 18:25 |
ion_ | I dunno. cancel-stop? :-P | 18:29 |
Keybuk | ion_: that'd mean a /usr/bin/cancel-stop? :p | 19:35 |
ion_ | Well, it would, and that would suck. :-P | 19:41 |
Keybuk | heh | 19:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!