[01:12] <rgl> hi
[01:13] <rgl> AlexExtreme, why is this """When a job is disabled by the current profile, it still responds to events, it'll just not actually start. If the system is currently in a state when it can be running, and the profile is changed to one which allows it to be run, it'll start.""" ?
[01:13] <rgl> why to refuse to start a job?
[01:13] <AlexExtreme> because that's what disabling a job is?
[01:13] <rgl> I mean, if the admin wants to start a job that is not in the current profile, why should he be refrained from starting it anyways?
[01:14] <rgl> for me "disabling" is "disabling the service from being automatically started"
[01:14] <AlexExtreme> rgl, it would only be disallowed from starting if the profile specifically states that that job is disabled, and even then it could still be started manually
[01:15] <rgl> yes, I understood that.  what I don't understant is why :D
[01:15] <rgl> "why you want to do that"
 for me "disabling" is "disabling the service from being automatically started"
[01:15] <AlexExtreme> that's exactly what it does...
[01:15] <Keybuk> sounds like you're both arguing for the same thing :)
[01:15] <AlexExtreme> you can still start it manually
[01:16] <rgl> ah :-)
[01:16] <rgl> sorry for the confusion :D
[01:18] <Keybuk> that makes the most sense to me as well
[01:18] <Keybuk> "disabled" jobs don't react to events, but still show up in lists, and can still be manually started/stopped
[01:20] <AlexExtreme> yeah
[01:29] <AlexExtreme> hmm
[01:31] <AlexExtreme> in terms of profiles, i'll be doing lookups by name quite often, both when parsing a profile and starting a job. so a hash would be more efficient
[01:31] <AlexExtreme> and i hadn't thought of using wildcards for job name matching. hrm
[01:41] <rgl> ah, so my email has something useful? :-)
[01:42] <AlexExtreme> yep :p
[01:55] <Keybuk> the interesting thing about Profiles, compared to the original Flags idea, is that Profiles are defined separately to Jobs
[01:55] <Keybuk> for Flags, the idea was that a Job listed the states it was enabled/disabled in
[01:55] <Keybuk> the thing I like about Profiles is that it's up to the sysadmin how Jobs are grouped
[01:55] <AlexExtreme> yes
[01:55] <AlexExtreme> IMO it's much more flexible
[01:56] <Keybuk> so this has got me thinking a bit
[01:56] <Keybuk> Profiles are fundamentally groups of Jobs
[01:56] <Keybuk> "these are the jobs that do things with networking"
[01:56] <Keybuk> "these are the jobs that do multi-user things"
[01:56] <Keybuk> "these are the jobs when the machine is acting as a web-server"
[01:57] <Keybuk> (I often used runlevel 3 in sysvinit for the latter, so I could turn on/off apache/postgresql/etc. which were expensive to run)
[01:58] <Keybuk> does that sound kinda right?
[01:58] <AlexExtreme> yeah
[01:59] <Keybuk> an interesting side-effect of the "disable means no auto-start" functionality is that if you disabled udev, then you inherently disable all jobs that react to udev events
[01:59] <Keybuk> so that's quite nice
[02:01] <rgl> can we please have multiple profiles active? :D
[02:01] <rgl> though, that goes against the word "profile", so maybe we should have job groups *G*
[02:02] <rgl> ("job groups" the name)
[02:02] <AlexExtreme> side note: i noticed the kbdrequest event earlier - what exactly is it useful for?
[02:06] <Keybuk> AlexExtreme: I think it's supposed to be "spawn a new getty" *shrug*
[02:06] <Keybuk> rgl: yeah, that's what I've been thinking
[02:06] <Keybuk> since a Profile basically acts as a group of Jobs
[02:06] <Keybuk> maybe we don't need to specify enable/disable in a profile
[02:07] <Keybuk> instead it just needs to include jobs by name
[02:07] <Keybuk> and then you can enable/disable a profile
[02:07] <AlexExtreme> this profiles idea gets more complicated by the day *g*
[02:08] <rgl> and have a directory with all the jobs in the profile (instead of a file;  like I've said some of this day hehe) *G*
[02:08] <AlexExtreme> no
[02:08] <AlexExtreme> i will never, ever have that. it'd be a complete mess. we might as well just go back to /etc/rc*.d...
[02:08] <Keybuk> rgl: why would a directory be good?  then a job couldn't be in multiple profiles
[02:09] <AlexExtreme> that'd be possible, of course, with nice symlinks all over the place
[02:09] <Keybuk> AlexExtreme: well, if a profile is just a list of jobs, and enabled/disabled, you just need to check whether any of the profiles the job is listed in are disabled
[02:09] <Keybuk> eww, symlinsk
[02:09] <Keybuk> symlinks are evil as a configuration mechanism
[02:10] <rgl> you chould just touch the file.
[02:10] <rgl> (no symlink)
[02:10] <Keybuk> empty files?
[02:10] <Keybuk> that's just as bad <g>
[02:10] <AlexExtreme> there'd be still little files everywhere
[02:10] <Keybuk> very djb-ish
[02:11] <AlexExtreme> yeah
[02:11] <AlexExtreme> that's what i hated with djb/runit :P
[02:11] <rgl> djb-ish is good for ya!
[02:11] <rgl> I love it :D
[02:11] <AlexExtreme> service == directory and scripts/files inside
[02:11] <AlexExtreme> why not just one file?
[02:12] <Keybuk> my Profiles musing went a bit further ,.. <g>
[02:12] <Keybuk> if a profile is a list of jobs, and if a profile can be disabled or enabled
[02:12] <rgl> its easier to admin using regular CLI tool?  touch/rm vs using a command to parse the file and do that.
[02:12] <Keybuk> then you could link profiles to a state <g>
[02:13] <AlexExtreme> rgl, how is it easier? it'd be a complete nightmare for the distro developers
[02:13] <rgl> AlexExtreme, nightmare?  why?
[02:13] <Keybuk> touch vs vi is pretty even
[02:14] <Keybuk> the modify command approach is better, since it can guarantee integrity
[02:14] <Keybuk> (what is the behaviour if you touch the name of a job that doesn't exist?)
[02:14] <rgl> Keybuk, its the same has using vi and inserting it in the profile file ;)
[02:15] <Keybuk> rgl: exactly, there's no admin difference
[02:16] <rgl> Keybuk, there is.  to enable a service you have to use upstart-profile-enable-service service vs touch something
[02:16] <Keybuk> ?
[02:16] <Keybuk> no, you can use vi
[02:17] <AlexExtreme> or easier:
[02:17] <AlexExtreme> echo "enable myjob" >> /etc/init/profiles.d/myprofile
[02:17] <rgl> Keybuk, why did debian decide to use enabled-sites/ directories instead of using "Include" in the file?
[02:17] <rgl> AlexExtreme, and to remove? :D
[02:18] <AlexExtreme> sed -i '/enable myjob/d' /etc/init/profiles.d/myprofile
[02:18] <rgl> AlexExtreme, my point is, you have to use a command for doing it.  but its a mater of taste *shrug*
[02:18] <rgl> AlexExtreme, obsioly, thats not that simple.
[02:19] <AlexExtreme> you have to use a command if you've got directories too
[02:19] <rgl> AlexExtreme, you have to skip comments, etc.
[02:20] <rgl> lets not paint the bikeshed anymore ;-)
[02:20] <Keybuk> rgl: how do you comment out the disabling of a service with your method?
[02:22] <rgl> Keybuk, humm, I was not thinking of disabling jobs.  this was a "enable only" thing.  if you want to disable the job, just rm the job from the profile.
[02:22] <AlexExtreme> take this as an example:
[02:22] <AlexExtreme> if a distro developer provided a job with a package and wanted that job enabled in all profiles by default
[02:22] <AlexExtreme> they'd have to go through each profile and add it in
[02:23] <Keybuk> rgl: no, I just want to comment it out for a while
[02:23] <Keybuk> you can't do that with the file technique
[02:23] <Keybuk> and you can't document why it's removed
[02:23] <Keybuk> # keybuk - think this is breaking networking - 02jun07
[02:23] <AlexExtreme> surely it would be easier to just put it in /etc/event.d or whatever and have the profile "enable/disable *" lines handle it
[02:23] <Keybuk> # ntpdate
[02:24] <rgl> AlexExtreme, document?  use a automated thing to administer your box? :D
[02:24] <rgl> err
[02:24] <rgl> that was for Keybuk :D
[02:25] <AlexExtreme> huh?
[02:25] <AlexExtreme> what has an "automated thing" got to do with anything?
[02:25] <rgl> AlexExtreme, with the "document" part that Keybuk said.   
[02:26] <AlexExtreme> i still don't get what it's got to do with that
[02:26] <AlexExtreme> brb, lunch
[02:27] <Keybuk> anyway, it's my bikeshed, and we're using configuration files; not directories-o-symlinks or djb madness <g>
[02:27] <rgl> I was just saying that the "document" part could be addressed by your automated tool.  (if you don't use one, yeah, it sux, and you can't document)
[02:28] <Keybuk> you can't document in the model you suggest though
[02:28] <rgl> Keybuk, fair enough :-)
[02:28] <Keybuk> you'd need another directory of documents about why things aren't in another one
[02:55] <AlexExtreme> btw Keybuk, it'd make sense to put all the profile stuff into a seperate source file (like profile.{c,h}) rather than sticking it onto the parsing stuff in cfgfile.c, right? if i were to put it in cfgfile.c it'd allow you to put job stanzas in profiles and vice-versa, which isn't what i want, really ;)
[03:26] <Keybuk> it should have a separate stanzas list, yes
[03:26] <AlexExtreme> k
[03:28] <Keybuk> that file is a little mixed up
[03:28] <Keybuk> since it has the parsing and watching code too
[03:28] <Keybuk> (which should be shared)
[03:43] <AlexExtreme> hmm, profile.c written. now to plug it in to the rest of upstart ;)
[03:49] <AlexExtreme> with what?
[03:50] <Keybuk> right now we're relying on the filesystem to provide the namespace
[03:50] <Keybuk> if we allow people to define multiple jobs in one file, how do we enforce that?
[03:50] <Keybuk> (likewise for profiles)
[03:51] <AlexExtreme> hmm
[03:55] <Keybuk> obviously we have to solve this if we want people to be able to register jobs over the initctl socket
[03:55] <AlexExtreme> i'm not quite sure i understand
[03:55] <Keybuk> well
[03:55] <Keybuk> let's say I make /etc/init/jobs.d/foo
[03:56] <Keybuk> and I also make /etc/init/upstart.conf and put
[03:56] <Keybuk>   job foo
[03:56] <Keybuk>     ...
[03:56] <Keybuk>   end foo
[03:56] <Keybuk> in it
[03:56] <Keybuk> which gets priority?
[03:56] <Keybuk> (and how do we stop them both fighting)
[03:56] <AlexExtreme> hrm
[03:57] <AlexExtreme> i would say the one in upstart.conf gets priority
[03:57] <AlexExtreme> take this as an example:
[03:57] <Keybuk> so the first one parsed?
[03:57] <AlexExtreme> a distribution provides a job called foo, and the user wants to override that job with their own version without editing the one provided by their distro
[03:57] <Keybuk> (assuming upstart.conf is registered first)
[03:58] <AlexExtreme> they could put their version in upstart.conf
[03:58] <AlexExtreme> and it would get priority
[03:58] <Keybuk> ok, and self-registered would take priority over that?
[03:58] <AlexExtreme> they could easily revert to the distros version by simply commenting out their version
[03:58] <AlexExtreme> yes
[03:58] <Keybuk> that makes it easy then
[03:58] <Keybuk> a Job just needs to know which CfgSource it was registered with
[03:58] <Keybuk> and when loading a job from a source, check the source is the same
[03:59] <Keybuk> though this means you can't move a job from one source to another
[03:59] <Keybuk> if you delete /etc/init.d/upstart.conf, the jobs.d/foo one wouldn't show up unless touched
[04:00] <AlexExtreme> it's not that big a problem, and if it could be solved by touching the other one, then it's a minor problem
[04:00] <Keybuk> I'd prefer it to be solved internally
[04:01] <Keybuk> we'd need a JobName structure that tracked, for a given name, what was available from each source, and whether each of those things had replacements
[04:06] <Keybuk> that's a bit sucky, since we'd need the same for Profile and State
[05:42] <AlexExtreme> hmm
[05:43] <AlexExtreme> say a job has been disabled in a profile, yet the sysadmin has started it manually. should the job respond to stop events?
[05:54] <rgl_> I think it should.
[05:54] <AlexExtreme> me too
[05:56] <Keybuk> yes
[05:56] <Keybuk> profiles should just affect start events
[05:56] <Keybuk> cf. job is running, and sysadmin disables the profile, it should still stop later
[05:57] <Keybuk> maybe it should stop immediately too
[06:01] <Keybuk> in theory, we should be able to use the same pattern for "state definition" and "profile definition"
[06:08] <AlexExtreme> you mean source file name?
[06:09] <Keybuk> yeah
[06:10] <AlexExtreme> parser.c ? :P
[06:11] <Keybuk> doesn't say "job" though
[06:11] <Keybuk> so we'd have to put state and profile parsing in the same file
[06:12] <AlexExtreme> jobparse.c
[06:13] <Keybuk> and stateparse.c and profileparse.c ?
[06:13] <AlexExtreme> hmm.
[06:13] <AlexExtreme> a bit long :p
[06:14] <Keybuk> heh
[06:14] <Keybuk> I didn't realise there was a length limit <g>
[06:15] <AlexExtreme> meh ;)
[06:17] <AlexExtreme> well, that's a start
[06:17] <AlexExtreme> the profile code compiled ;)
[06:17] <AlexExtreme> i'll test it in a minute :P

[06:18] <Keybuk> you're supposed to write the tests *first* :p
[06:25] <Keybuk> (not that I ever do)
[06:31] <AlexExtreme> :P
[06:32] <wasabi> Heh. I've never found TDD works on a budget.
[06:33] <Keybuk> I find that about 75% of my coding time is spent refactoring test cases
[06:33] <Keybuk> which is about the same amount of time I spent figuring out how I broke things
[06:33] <AlexExtreme> heh
[06:33] <AlexExtreme> ok, brb. if i don't come back, you'll know it hasn't worked :p
[06:33] <Keybuk> the net gain of course, is that the 75% now happens *before* I ship the tarball
[06:34] <Keybuk> AlexExtreme: just comment out the bits of main.c that assume pid()==1 :p
[06:37] <AlexExtreme> yeeep, i broke it :P
[06:41] <Keybuk> lol
[06:41] <AlexExtreme> somehow i'm getting an assertion failure on line 521 in string.c
[06:42] <AlexExtreme> how, i don't know, because i'm never calling the function that's it
[06:43] <AlexExtreme> *in
[06:44] <Keybuk> lol
[06:44] <Keybuk> what's the backtrace?
[06:45] <AlexExtreme> where does that come from? :p
[06:45] <AlexExtreme> core dump?
[06:47] <Keybuk> yeah
[06:47] <AlexExtreme> hmm
[06:47] <AlexExtreme> it would help if the FS was read write
[06:47] <AlexExtreme> hang on :p
[06:52] <Keybuk> test_cfgfile.c is annoying long
[06:59] <AlexExtreme> hmm
[06:59] <AlexExtreme> well the core dump was officially useless
[07:00] <AlexExtreme> init was compiled without debug symbols :P
[07:02] <AlexExtreme> ahhhh
[07:02] <AlexExtreme> i see what i did wrong :p
[07:03] <Keybuk> --disable-compiler-optimisations --disable-linker-optimisations --enable-warnings
[07:03] <Keybuk> :P
[07:03] <AlexExtreme> profile_get_job_status (job) << usually it helps to pass job->name to that function
[07:07] <AlexExtreme> let's try again ;)
[07:19] <wasabi> Keybuk: Yeah, which is great, when you're not on a budget. ;)
[07:19] <wasabi> Otherwise shipping the 75% is acceptable. Heh.
[07:26] <AlexExtreme> so it appears i'm managing to do something weird to job->cause
[07:26] <AlexExtreme> brb, dinner
[07:57] <Keybuk> woo, test passes
[07:58] <Keybuk> now to fix valgrind
[08:00] <Keybuk> easy; just a couple of "returning without freeing if -ENOMEM" bugs
[08:01] <AlexExtreme> it's interesting to note that i still get this assert failed if i revert all my changes
[08:03] <rgl_> how you guys test upstart?  using UML?
[08:03] <Keybuk> odd
[08:03] <Keybuk> rgl_: "make check"
[08:03] <rgl_> how do I run upstart without being proc #1?
[08:03] <AlexExtreme> let's try the completely vanilla tree
[08:04] <Keybuk> rgl_: you can't at the moment, without patching the code
[08:05] <rgl_> Keybuk, so make check tests a running upstart?
[08:05] <AlexExtreme> no, it tests the code
[08:05] <Keybuk> rgl_: no, it's a suite of stuff that tests the code
[08:05] <Keybuk> unit tests, basically
[08:06] <rgl_> ah, no integration tests yet. ok.
[08:07] <AlexExtreme> ok, i'm getting this bug with a vanilla tree
[08:07] <AlexExtreme> Keybuk, want a backtrace?
[08:08] <Keybuk> sure
[08:08] <Keybuk> rgl_: define integration tests, in this case
[08:09] <AlexExtreme> Keybuk, http://frugalware.org/paste/1480
[08:09] <Keybuk> I've never been clear exactly where unit and integration testing are supposed to be different
[08:10] <Keybuk> since pure unit testing supposes you can test just one function
[08:10] <Keybuk> (which you never can)
[08:11] <Keybuk> AlexExtreme: which upstart version?
[08:11] <AlexExtreme> it's latest bzr
[08:11] <AlexExtreme> 0.3.8 works fine
[08:11] <Keybuk> ah, interesting
[08:12] <Keybuk>         * init/event.c (event_new): Start off with NULL args and env, to
[08:12] <Keybuk>         match job (saves a few bytes).
[08:12] <Keybuk>         (event_match): Watch for NULL arguments!
[08:12] <Keybuk>         * init/tests/test_event.c (test_new): Check for NULL not alloc'd
[08:12] <Keybuk> heh
[08:13] <rgl_> Keybuk, test the whole shebang as a blackbox.  like, have some jobs, kill a job, see if its restarted, and stff like that.  also, test the "problem" I've mention a days before: edit job, start a service that is a symlink, and see it does not work.
[08:14] <Keybuk> AlexExtreme: if statement on job.c 1372 needs "&& job->cause->info.args" added
[08:15] <Keybuk> rgl_: that's System Testing
[08:16] <rgl_> Keybuk, isn't that the same as integration tests?
[08:16] <rgl_> (though, its the first time I've heard of system testing hehe)
[08:17] <Keybuk> well
[08:17] <Keybuk> usually you're supposed to have
[08:17] <Keybuk> Unit Testing -> Integration Testing -> System Testing
[08:17] <Keybuk> unit supposes you can test each individual function
[08:17] <Keybuk> integration is where you join functions together, and run scenarios through it
[08:18] <AlexExtreme> ok, let's test that
[08:18] <AlexExtreme> brb
[08:18] <Keybuk> system is when you have the finished system, and apply checks to make sure it works
[08:18] <Keybuk> the Upstart test suite is something of a combination of Unit (where possible) and Integration
[08:19] <Keybuk> frequently tests are running much of the Upstart code
[08:19] <Keybuk> e.g. we have tests to set up a socket, and all of the code to listen to it, then we poke commands into it and see how the states of jobs change, and what events are emitted, etc.
[08:19] <rgl_> ah alright :D
[08:19] <Keybuk> System Testing is when I install and reboot
[08:20] <Keybuk> and if it fails, then I don't get to my desktop, so I can't upload the tarball <g>
[08:20] <rgl_> hehe
[08:20] <rgl_> though, using UML could facilitate that (but for sure you known it hehe)
[08:21] <Keybuk> I don't know UML
[08:21] <Keybuk> or do you mean User-Mode-Linux?
[08:21] <AlexExtreme> I use VMware for that kinda thing :p
[08:21] <rgl_> oh yes, sorry.  yes.  user-mode-linux
[08:21] <AlexExtreme> mental note: it helps to apply the fix before testing it
[08:21] <Keybuk> yeah, I use vmware for some stuff
[08:21] <Keybuk> though mostly I just install it and see what happens
[08:22] <AlexExtreme> Keybuk, what line was it on (the if block to change)?
[08:22] <Keybuk> 1372
[08:23] <Keybuk> is it bad to push incomplete code to main? :p
[08:23] <AlexExtreme> as long as i don't bzr pull :p
[08:23] <Keybuk> lol
[08:23] <Keybuk> you wouldn't be able to, you're diverged now, no?
[08:24] <AlexExtreme> true
[08:24] <AlexExtreme> if it works this time i'll commit it to a new branch
[08:25] <AlexExtreme> brb
[08:27] <AlexExtreme> OMG
[08:27] <AlexExtreme> It worked :P
[08:32] <AlexExtreme> bbl
[09:23] <AlexExtreme> https://code.launchpad.net/~alex-extreme2/upstart/profiles
[10:02] <AlexExtreme> night