| === Vlan [i=Vlan@c9.vl.net.ua] has left #upstart [] | ||
| === Seveas [n=seveas@ubuntu/member/seveas] has joined #upstart | ||
| === theCore_ [n=alex@ubuntu/member/theCore] has joined #upstart | ||
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| === Keybuk [n=scott@wing-commander.netsplit.com] has joined #upstart | ||
| Keybuk | interesting | 02:28 |
|---|---|---|
| Keybuk | Jimmy has "quit" initNG | 02:29 |
| Keybuk | and some fun stats | 02:31 |
| Keybuk | development from scratch to 0.2.7 (which was in edgy) | 02:32 |
| Keybuk | 62 files changed, 19961 insertions(+) | 02:32 |
| Keybuk | development since then | 02:32 |
| Keybuk | 68 files changed, 18083 insertions(+), 9995 deletions(-) | 02:32 |
| === j_ack [n=rudi@p508DAA7D.dip0.t-ipconnect.de] has joined #upstart | ||
| pkt | hi Keybuk | 04:09 |
| Keybuk | hihi | 04:10 |
| pkt | how is progress on upstart scripts? | 04:10 |
| Keybuk | pkt: for feisty? we haven't formally begun them yet, though they're all mapped out | 04:11 |
| pkt | ah, ok | 04:11 |
| pkt | I 'm hoping to use upstart for my private (LFS-based) distro | 04:12 |
| Keybuk | current timeline | 04:12 |
| Keybuk | 0.3.2 today if I can | 04:12 |
| Keybuk | that fixes all of the "rushed" code in 0.2.7, and introduces a stable IPC layer, etc. | 04:12 |
| pkt | nice to hear that :-) | 04:13 |
| Keybuk | then I start on the proper features listed in the wiki for the 0.3 milestone | 04:13 |
| Keybuk | https://launchpad.net/upstart/+milestone/0.3 | 04:13 |
| === pkt looks ... | ||
| Keybuk | most of those make changes to the job structure that we wanted to do the startup scripts | 04:14 |
| Keybuk | so I hope to have those done over the next week or two after 0.3.2 | 04:15 |
| Keybuk | leaving a few weeks to do the boot scripts themselves | 04:15 |
| pkt | ah, ok so you suggest to take a look again in a few weeks correct? | 04:16 |
| Keybuk | so the first run of those should be done by Feb 8th | 04:16 |
| pkt | btw, have you looked at depinit? | 04:16 |
| Keybuk | no, URL? | 04:18 |
| pkt | wait a sec .. | 04:18 |
| pkt | ha! found it http://www.nezumi.plus.com/depinit/ | 04:21 |
| pkt | It has some interesting features | 04:21 |
| pkt | like using different signals to stop daemons and shells | 04:21 |
| pkt | reliable loggers (from daemontools) etc | 04:21 |
| pkt | of course it is primitive and never had a development community with size > 1 | 04:22 |
| pkt | but it has some nice ideas to get inspiration from | 04:22 |
| Keybuk | never seen that one before | 04:24 |
| pkt | mostly only old LFSers know about it | 04:25 |
| pkt | btw, the author released a newer version and probably forgot to update the page | 04:26 |
| pkt | so the last (known to me) version is probably http://www.nezumi.plus.com/depinit/depinit-0.1.5.tar.bz2 | 04:27 |
| Keybuk | tbh, from a glance at the features list, there's not much there that'd be useful to us | 04:27 |
| Keybuk | a lot of it is to do with being a dependency-based init system, which upstart is expressly not | 04:28 |
| pkt | well some of its "side" features are interesting | 04:28 |
| pkt | like pipelines between daemons for reliable logging | 04:29 |
| pkt | I 'll probably try to port some of the interesting stuff to upstart | 04:30 |
| pkt | (assuming I 'm able to base my system on it first) | 04:30 |
| Keybuk | yeah, that bit's kinda interesting | 04:30 |
| _ion | Would 'state' work as the 'FOO'? | 04:36 |
| _ion | It's somewhat ambiguous, admittedly. | 04:36 |
| Keybuk | "the 'FOO'" ? | 04:47 |
| _ion | https://lists.ubuntu.com/archives/upstart-devel/2006-December/000200.html | 05:00 |
| === maro [n=mark@0x55511dab.adsl.cybercity.dk] has joined #upstart | ||
| === j_ack [n=rudi@p508DAA7D.dip0.t-ipconnect.de] has joined #upstart | ||
| AlexExtreme | hrm | 07:48 |
| AlexExtreme | Keybuk, what was the alternative to the Profiles spec? | 07:48 |
| Keybuk | Flags | 07:49 |
| Keybuk | there's no spec for that one yet | 07:49 |
| AlexExtreme | and what did it involve? passing parameters on the kernel command line? | 07:49 |
| Keybuk | profiles, iirc, involves defining lists of jobs either by include or exclude | 07:52 |
| Keybuk | so you'd have the "with networking" profile which would include jobs that are excluded by the "without networking" profile,e tc. | 07:53 |
| Keybuk | those profiles would have to be defined elsewhere | 07:53 |
| Keybuk | they're a bit like existing runlevels, or initng goals | 07:53 |
| Keybuk | and would have to be maintained by hand | 07:53 |
| AlexExtreme | yes, I wrote a spec for that | 07:53 |
| Keybuk | *nods* | 07:53 |
| Keybuk | Flags was an alternate idea | 07:53 |
| Keybuk | they'd be states that were either up or down, and set by the kernel by default | 07:54 |
| Keybuk | uh, kernel command-line | 07:54 |
| Keybuk | obviously ;p | 07:54 |
| Keybuk | so you could have a networking flag, a multi-user flag, etc. | 07:54 |
| AlexExtreme | I'd definitely prefer the profiles idea | 07:55 |
| Keybuk | jobs can then say "if FLAG" or "unless FLAG" | 07:55 |
| Keybuk | the advantage to flags is they're more flexible | 07:55 |
| Keybuk | FOO (network-up until network-down if networking) or if multi-user | 07:55 |
| AlexExtreme | but, when we write a gui to configure upstart, it would have to detect which bootloader is in use and modify it's configuration file | 07:56 |
| AlexExtreme | to set the kernel command line | 07:56 |
| Keybuk | ah no :) | 07:56 |
| Keybuk | flags are just command-less jobs | 07:56 |
| Keybuk | so there's an /etc/event.d/networking that has "start on startup" in it | 07:56 |
| Keybuk | or something like that, anyway | 07:56 |
| Keybuk | which flags were up or down is the only thing dictated by the kernel command line | 07:57 |
| Keybuk | which is the same with profiles; which profile you're in is dictated by the kernel command line | 07:57 |
| Keybuk | the difference is the method of inclusion of jobs into them | 07:57 |
| Keybuk | profiles is defined by seperate files | 07:57 |
| Keybuk | flags are defined within the job file | 07:57 |
| AlexExtreme | mmm | 07:57 |
| AlexExtreme | you've lost me :) | 07:59 |
| Keybuk | heh | 07:59 |
| Keybuk | I need to write the spec | 07:59 |
| Keybuk | or wasabi does :p | 07:59 |
| Keybuk | I don't particularly favour or disfavour either of them | 08:03 |
| AlexExtreme | i'd certainly prefer profiles | 08:03 |
| wasabi | Hmmm. | 08:04 |
| wasabi | lemmie load that back into my head | 08:04 |
| wasabi | it's long been swapped out | 08:04 |
| wasabi | I think I have a natural tendency to suport, as much as possible, alterting the obvious parts of the configuration without modifying the job files themselves. | 08:05 |
| wasabi | modifying the job files themselves introduces an upgrade issue. | 08:05 |
| wasabi | Hmm. Cept that isn't an issue. | 08:06 |
| wasabi | HMMM. | 08:06 |
| AlexExtreme | Well, flags would require some modification of job files, definitely | 08:06 |
| wasabi | So, a flag would be a job named 'flag-networking' or something. And the actual network scripts would define a level between flag-networking started and flag-networking stopped | 08:06 |
| Keybuk | if profiles are stored in a configuration file, then that still has the same upgrade issue | 08:07 |
| Keybuk | you'd end up with conflicts modifying /etc/bootprofiles | 08:07 |
| wasabi | Then you could use hte kernel commad line to make the system boot into a state where flag-networking is "started" | 08:07 |
| Keybuk | if they were directories of symlinks, otoh ... | 08:07 |
| wasabi | Which is an unnatural state, as nothing starts flag-networking, ever, except that. | 08:07 |
| wasabi | Yeah, Keybuk, that's why I just now realized it was a non-issue. | 08:07 |
| wasabi | I don't think we want users modifying profiles. | 08:08 |
| AlexExtreme | but what if they want to disable services? | 08:08 |
| wasabi | I think they'll end up being more of a tool for us. | 08:08 |
| wasabi | like safe-mode is for windows. | 08:08 |
| Keybuk | AlexExtreme: define disable | 08:08 |
| Keybuk | does disable mean that "start JOB" will return "DISABLED" | 08:09 |
| AlexExtreme | stop a service from starting | 08:09 |
| wasabi | Maybe disabling services BY THE USER, is a completely seperate act from defining run states. | 08:09 |
| Keybuk | or does it mean it's just not started by its usual events? | 08:09 |
| Keybuk | and that a sysadmin can still start it manually? | 08:09 |
| AlexExtreme | yes they could still start it manually, just wouldn't be started at boot | 08:09 |
| wasabi | How are we with adding a "disabled" line-item to the job definition? | 08:09 |
| wasabi | And making an installer merge? | 08:10 |
| wasabi | Which is what we already have I think. | 08:10 |
| wasabi | And defining boot profiles using distro-supplied files. | 08:10 |
| wasabi | Such as extra jub definitions. | 08:10 |
| wasabi | lemmie write that out once. | 08:11 |
| Keybuk | that makes adding disabled equivalent to commenting out the start events :) | 08:11 |
| AlexExtreme | basically, all I'm concerned about is having a system where you can stop services from being started at boot | 08:11 |
| Keybuk | both are job file edits | 08:11 |
| Keybuk | something in SMF(?) I liked ... | 08:11 |
| Keybuk | if you list jobs on the kernel command line, they're started at boot automatically | 08:11 |
| Keybuk | if you list them with "!" in front, they're not started | 08:12 |
| wasabi | Okay, lets wait a second, we have one up front question we need to clear up. | 08:12 |
| wasabi | Should we EXPECT< during normal OS operation, the user to edit the distributed job files to change stuff. If yes: are we willing to take care of that during hte upgrade procedure. | 08:13 |
| wasabi | There's not much doubt in my mind that "turning off a service" is normal OS operation. | 08:13 |
| wasabi | And I suspect we'll have lovely and wonderful UI's that do it in the future. | 08:13 |
| Keybuk | I think that normal users will likely only want to disable or enable services/tasks | 08:13 |
| Keybuk | advanced users may wish to configure when services/tasks are run | 08:14 |
| Keybuk | and advanced users may also wish to modify them | 08:14 |
| wasabi | Yes, we need to plan for the normal use case. | 08:14 |
| AlexExtreme | yes | 08:14 |
| wasabi | Some guy sitting down at his server and flipping a switch to turn off apache. | 08:14 |
| wasabi | That seems pretty understandable to me. | 08:14 |
| wasabi | If apache is configured wrong, that's a bug. | 08:14 |
| wasabi | Or if it starts at the wrong times so he has to edit the files, it's a bug. | 08:15 |
| wasabi | (or a missing feature) | 08:15 |
| wasabi | So, if we put "disabled" in the job file, we commit to making the upgrade scripts detect and remember it. | 08:16 |
| AlexExtreme | But I don't think editing the job file is the best way of doing it | 08:16 |
| wasabi | I'm unsure if it is. Adding one line "disabled" isn't the hardest thing to build a merge for. | 08:19 |
| AlexExtreme | If there was a line that could be added in the job file, 'required', then that job would always be started, for example in udev's job file. Then anything that hasn't got required in could be overridden. Having a line like '!foo' in say, /etc/bootprofiles, under a profile section would disable foo in the profile it's listed under | 08:19 |
| Keybuk | why is udev required? | 08:20 |
| AlexExtreme | it was just an example ;) | 08:20 |
| wasabi | one thing at a time. Are we going to merge job files? :) | 08:20 |
| Keybuk | wasabi: I tend to think that needs human intervention | 08:21 |
| AlexExtreme | It'd certainly be easier not to | 08:21 |
| Keybuk | e.g. user adds "limit core 0 0", distro adds "limit core 100 100" | 08:21 |
| Keybuk | you need a human to resolve that | 08:21 |
| wasabi | Yup. I mean, we can merge SIMPLE stuff. | 08:21 |
| wasabi | We could merge "disabled", and prompt on anything else. | 08:21 |
| wasabi | if disabled in old; if !disabled in new; add disabled to new | 08:22 |
| AlexExtreme | Prompting wouldn't be good, there are distros (including Frugalware) that don't like having the upgrade process interactive | 08:22 |
| wasabi | Prompting would only happen if the user changed stuff manually. | 08:22 |
| wasabi | Other than disabled. | 08:23 |
| AlexExtreme | It'd make 'update-manager -d' more difficult, too | 08:23 |
| Keybuk | Ubuntu forbids prompting also | 08:23 |
| Keybuk | (well, where the user didn't change anything) | 08:23 |
| wasabi | Prompting in ALL cases? Even if the USER went in and edited a text file? | 08:23 |
| wasabi | Okay. Heh. | 08:23 |
| wasabi | I would be fine with disabled being in the job files, and handled silent during upgrade. | 08:28 |
| wasabi | I think that's fairly easy to do. | 08:28 |
| wasabi | So, that takes care of the user being able to disable services from some UI of some sort. | 08:29 |
| wasabi | On to profiles. Who are these for? | 08:29 |
| wasabi | I don't, or can't yet see, any reason to support allowing users to write their own profiles. | 08:30 |
| wasabi | I suspect we'll just want to use these to drive out stuff like a Safe Mode boot prompt. | 08:30 |
| wasabi | Where X doesn't start, and maybe no networking or something. | 08:30 |
| AlexExtreme | Hmm. | 08:31 |
| wasabi | I think at it's simpliest this could be accomplished by letting the distro define a few items they want to provide to their users, no X, no network, etc... and implement those in the job files THEY distribute. | 08:31 |
| wasabi | And I think as Keybuk mentioned earlier, these are actually just flags. | 08:32 |
| AlexExtreme | All the examples I came up with in my head for using profiles can be solved with events :p | 08:32 |
| AlexExtreme | Gotta disappear for half an hour, bbl | 08:32 |
| wasabi | These don't HAVE to be anything more than a set of flags which a service can choose to check to disable itself. | 08:32 |
| === mbiebl [n=michael@e180122163.adsl.alicedsl.de] has joined #upstart | ||
| _ion | Switch to libelektra and forget about any problems with syncing config files. ;-) | 08:44 |
| Keybuk | that looks a lot like gconf | 08:44 |
| Keybuk | which has the same problems :p | 08:44 |
| Keybuk | and it used leverage on the first paragraph of its website | 08:45 |
| Keybuk | hmm, there's nothing there that eliminates upgrade issues that I can see? | 08:45 |
| === j_ack [n=rudi@p508DAA7D.dip0.t-ipconnect.de] has joined #upstart | ||
| _ion | I was under the impression that there would be a system config tree (parts of which would be updated when upgrading software) and a user config tree (corresponding to /etc) which would override key/value pairs in the system config tree, but maybe i remembered wrong; i don't seem to find such information from the website. | 08:51 |
| Keybuk | yes | 08:52 |
| Keybuk | so then you update the system config tree | 08:52 |
| Keybuk | but if the user has logged in and used the app, they'd be using the user config tree instead | 08:52 |
| Keybuk | so wouldn't get the change | 08:52 |
| Keybuk | cf. gconf | 08:52 |
| _ion | If that happens, the system hasn't been designed correctly. | 08:53 |
| _ion | If root disables a certain job, the only thing that should be added to the user tree would be the "disabled" key. | 08:53 |
| Keybuk | bzzt | 08:54 |
| _ion | Not a full copy of the settings from the system tree. | 08:54 |
| Keybuk | that way lies madness | 08:54 |
| Keybuk | because now you have an application that has to handle BOTH v1 and v2 config keys | 08:54 |
| Keybuk | which may have different formats | 08:54 |
| Keybuk | in fact, it has to handle every possible combination of every possible key it's ever used | 08:54 |
| Keybuk | also | 08:54 |
| Keybuk | what user doesn't open up every preference dialog for a look at some point or other? | 08:54 |
| Keybuk | if you only write when the user toggles ... do you delete the key from the user tree if they put it back to the default? | 08:54 |
| Keybuk | AND to make matters worse | 08:55 |
| Keybuk | if you don't copy the entire tree | 08:55 |
| _ion | Valid points. | 08:55 |
| Keybuk | you now have the "I configured my app, was perfectly happy with it, AND AN UPGRADE CHANGED THE WAY IT WORKED!!(*"(*(*" problem | 08:55 |
| Keybuk | simply because the user didn't look at that page, or didn't toggle that option on/off, ect. | 08:56 |
| Keybuk | difficult problem :p | 09:00 |
| _ion | So it seems that whatever we do (re: the "updated config file" issue, out of upstart's context), we lose. :-) | 09:00 |
| _ion | Every path seems to have compromises. | 09:01 |
| AlexExtreme | back | 09:12 |
| AlexExtreme | All I can say is that we simply add a file in /etc containing a list of services that the user *doesn't* want to start, and upgrade wouldn't touch that. The file would be updated by a config gui or by a command line tool like gentoo's rc-update. | 09:21 |
| === jonib1 [n=jonas@ua-83-227-144-18.cust.bredbandsbolaget.se] has joined #upstart | ||
| === jonib1 [n=jonas@ua-83-227-144-18.cust.bredbandsbolaget.se] has joined #upstart | ||
| === juergbi [n=juerg@80-219-19-246.dclient.hispeed.ch] has joined #upstart | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!