| === robbiew is now known as robbiew_ | ||
| Keybuk | ion: vague zany idea, remove some of the need for stanzas in the job format | 14:04 |
|---|---|---|
| Keybuk | e.g. instead of | 14:04 |
| Keybuk | env FOO="some value" | 14:04 |
| Keybuk | just have | 14:04 |
| Keybuk | FOO="some value" | 14:04 |
| Keybuk | could introduce some nice features that way | 14:04 |
| Keybuk | while apache | 14:04 |
| Keybuk | every hour | 14:05 |
| Keybuk | exec log-rotate | 14:05 |
| Keybuk | restart apache | 14:05 |
| Keybuk | -- | 14:05 |
| Keybuk | where "restart" is exactly equivalent to | 14:05 |
| Keybuk | script | 14:05 |
| Keybuk | exec log-rotate | 14:05 |
| Keybuk | restart apache | 14:05 |
| Keybuk | end script | 14:05 |
| Keybuk | type things | 14:05 |
| Keybuk | except obviously without the exec there :p | 14:05 |
| ion | Sounds good | 14:05 |
| Keybuk | then I was thinking that things like "on" could bind to whatever follows | 14:06 |
| Keybuk | while apache | 14:06 |
| Keybuk | 14:06 | |
| Keybuk | every hour | 14:06 |
| Keybuk | exec log-rotate | 14:06 |
| Keybuk | 14:06 | |
| Keybuk | every day | 14:06 |
| Keybuk | exec log-rotate --force | 14:06 |
| Keybuk | 14:06 | |
| Keybuk | on omg-the-world-is-over | 14:06 |
| Keybuk | restart apache | 14:07 |
| Keybuk | which is kinda cute for sub-jobs without needing a block | 14:07 |
| * sadmac considers whether he has to do anything nasty to his parser now | 14:07 | |
| sadmac | should be ok.... | 14:07 |
| Keybuk | sadmac: it was reading your parser code that made me think about it | 14:07 |
| sadmac | Keybuk: ah, cool | 14:07 |
| Keybuk | as can be more flexible | 14:08 |
| sadmac | I've been working on nih_parse_tool, which will work like yacc and turn a DSL into a C code parser | 14:09 |
| ion | Nice | 14:10 |
| sadmac | starting to appreciate how much of a pain actually processing these parse trees can be, but I think the parse tool will make it pretty straightforward | 14:10 |
| sadmac | and it'll get rid of the need to specify charsets manually, which normally requires a calculator and causes anneurisms. | 14:11 |
| Keybuk | so nobody hates the idea that on would bind like that? | 14:16 |
| sadmac | Keybuk: I wouldn't mind playing with it | 14:16 |
| ion | As long as how other things such as env, instance etc. are clearly defined. | 14:17 |
| sadmac | Keybuk: it may mean that the next job format isn't a strict superset of 0.6, which means more acrobatics to do that backward compatibility thing you promised | 14:17 |
| Keybuk | sadmac: 0.6 doesn't support bare "on" - so it should be fine | 14:18 |
| sadmac | Keybuk: right, but as of now we can only have one job format and get away with everything. We just neglect to remove start on/stop on and the 0.6 grammar is a subset of the 1.0 grammar. | 14:19 |
| sadmac | Keybuk: this way we might need two separate parsers. | 14:19 |
| sadmac | Keybuk: oh, I see what you're saying though... yeah could be. | 14:19 |
| Keybuk | ie. using "on", "every", "at" type keywords, everything after that is strict 1.0 grammar | 14:20 |
| Keybuk | but up until then, you can get away with some older grammar | 14:20 |
| sadmac | so it'd be jobfile = stanzas06* stanzas10* | 14:22 |
| Keybuk | right | 14:22 |
| Keybuk | tbh, we can even get away with "as soon as you put any 1.0 format thing in there, then the entire file must be 1.0 not 0.6" | 14:22 |
| Keybuk | since the point of the compatibility is to make sure existing jobs work | 14:23 |
| sadmac | jobfile = stanzas06* EOF | stanzas10* EOF | 14:23 |
| Keybuk | right | 14:23 |
| Keybuk | the only really ambiguous bit is the double stanzas crap | 14:24 |
| Keybuk | a file containing just: | 14:24 |
| sadmac | ugh. that ends up being kinda slow because we parse as much of the file as we can as 0.6, until we find a 1.0 thing. then we start over | 14:24 |
| Keybuk | exec foo | 14:24 |
| Keybuk | exec bar | 14:24 |
| Keybuk | I'd do it the other way - parse as 1.0 until we fail, then go back and see if it parses as 0.6 | 14:24 |
| sadmac | that works too. | 14:24 |
| Keybuk | parse errors can even be tagged "but might work on 0.6" | 14:26 |
| Keybuk | e.g. | 14:26 |
| Keybuk | the second exec there would be a parse error tagged "but try 0.6" | 14:26 |
| sadmac | that's the last thing I'll need to go back and do is the error reporting | 14:28 |
| ion | keybuk: Re: “implementing serialized startup sequence”: we talked about Upstart implementing similar priority stuff as what mountall is doing for fscks at the moment. I wonder if that would be useful for them as well? | 15:49 |
| Keybuk | entirely possibly | 15:50 |
| Keybuk | first I want to figure out what they mean | 15:50 |
| Keybuk | I still don't know where the whole M{oblin,aemo,eego} thing is going | 15:50 |
| ion | keybuk: An initial idea for the config syntax: ‘priority 1; locks sda sdb’: the job has internal exclusive locks named ‘sda’ and ‘sdb’ while running. Whenever a pending job is considered for getting to start next, consider the highest-priority ones first, the default priority being zero. ‘priority -5; contends-io sda sdb’: no actual locking, but the highest-priority one (falling back to first-come first-served) per “lock” names gets the IO ... | 16:07 |
| ion | ... priority at any given moment. Just like what mountall does, but with an optional priority integer. ‘contends-cpu foo bar baz’: same, but for niceness. | 16:07 |
| Keybuk | http://upstart.ubuntu.com/wiki/Resources | 16:08 |
| Keybuk | written in 1882 or something <g> | 16:08 |
| ion | Ah, i didn’t even remember about that one. | 16:08 |
| ion | As for what i wrote, the ‘locks X’, ‘contends-io Y’ and ‘contends-cpu Z’ tags should all be in their own namespaces, so foo.conf: ‘locks bla’ and bar.conf: ‘contends-io bla’ would not affect each other. | 16:10 |
| ion | So ‘contends-io sda sdb; contends-cpu sda sdb’ would do both IO and niceness priorization. | 16:11 |
| Keybuk | makes sense | 16:11 |
| sadmac | Keybuk: any other thoughts on nih-parse while you were looking at it? I guess its at least clean enough now that you can tell what the code does :) | 17:23 |
| Keybuk | the code is still ick | 17:24 |
| Keybuk | I don't like giant macros like that | 17:24 |
| Keybuk | you're from North Carolina | 17:25 |
| Keybuk | we have to assume that, at some point over the next couple of years, you are going to get murderer | 17:25 |
| Keybuk | or at least shot | 17:25 |
| Keybuk | so it has to be maintainable once you're gone :p | 17:25 |
| sadmac | Keybuk: I get murderer and murderer every day. | 17:25 |
| sadmac | Keybuk: I more or less agree. I know I can at least remove the per-function structs. After that some of the macros might even be able to become functions. | 17:26 |
| Keybuk | that would be yay | 17:27 |
| sadmac | Keybuk: I've spent a lot of time trying to figure out how I wrote it as easily as I did in the first place. It ran pretty much the first time. | 17:32 |
| === rberger_ is now known as rberger | ||
| === rberger_ is now known as rberger | ||
| === rberger_ is now known as rberger | ||
| NoReflex | hello! I'm having some problems with upstart in karmic server 64bit. It won't start postgresql. I tried http://superuser.com/questions/98702/how-to-make-postgresql-start-at-boot-time-in-ubuntu but it didn't work. can I remove upstart? I'm afraid to test it because the machine is at a remote location and if I mess it up I won't be able to connect to it anymore. | 22:13 |
| NoReflex | I can start postgresql using /etc/init.d/postgresql-8.4 manually after login. There are links in /etc/rc*.d to postgresql init script but for some reason it isn't started automatically after reboot | 22:14 |
| NoReflex | the channel says Upstart 0.6.5 "Our last, best hope for victory" ... should I try this version? is it dangerous? | 22:18 |
| NoReflex | I also searched for a logging possibility because I don't know why it won't start....and it's hard to "debug" a problem when you don't have the error message | 22:19 |
| NoReflex | any ideas? | 22:27 |
| NoReflex | Can I replace upstart with the old init package? | 22:28 |
| NoReflex | anybody? | 22:35 |
| mbiebl | NoReflex: I don't think you can. | 22:46 |
| mbiebl | Most of the core init scripts (rcS stage) have been converted to upstart-only | 22:46 |
| mbiebl | I don't see, why starting sysv init scripts for runlevel 2 should be a problem. | 22:48 |
| mbiebl | do you have a bug report maybe? | 22:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!