| sadmac2 | Keybuk: Have we decided what kind of info pid 1 will provide? i.e. is it just a feed of signals and other happenings or is it a Start-Stopped-Failed-Restarting kind of abstraction? | 19:53 |
|---|---|---|
| Keybuk | probably the same basic signals we have today | 19:53 |
| Keybuk | starting (lower left edge) | 19:54 |
| Keybuk | started (upper left edge) | 19:54 |
| Keybuk | stopping (upper right edge) | 19:54 |
| Keybuk | stopped (lower right edge) | 19:54 |
| Keybuk | where stopping and stopped will include properties containing exit codes, signals, output, etc. | 19:54 |
| sadmac2 | yes. that's good | 19:54 |
| sadmac2 | that's more useful to people who want to use pid 1 directly without the state service | 19:55 |
| sadmac2 | and it makes it easier to manage the state service itself | 19:55 |
| sadmac2 | BTW I think pid 1 should handle respawning transparently | 19:55 |
| Keybuk | respawning is interesting | 19:56 |
| Keybuk | as to whether or not you go through the levels | 19:56 |
| sadmac2 | it can be reflected in the state machine, but it means 3 states for a single job (one for running, one for trying to respawn, one for either of the above) | 19:57 |
| Keybuk | that's how I used to have it | 19:58 |
| Keybuk | but I couldn't find any reason for having that magic third state | 19:58 |
| Keybuk | at the end of the day, if you're depending on a service, and that service is restarted | 19:58 |
| Keybuk | most likely, you have to be restarted too | 19:58 |
| sadmac2 | with deps, there could be a serious falldown if that happens | 19:58 |
| Keybuk | d-bus crashes | 19:59 |
| Keybuk | and gets respawned | 19:59 |
| sadmac2 | whole system bounces | 19:59 |
| notting | d-bus is not allowed to crash. especially if it's in the kernel | 20:00 |
| Keybuk | it has to bounce though | 20:00 |
| Keybuk | if d-bus crashes, we really do have to restart everything that depended on it | 20:00 |
| Keybuk | it might be scary behaviour, but it's correct | 20:00 |
| notting | every time that gets brought up to the d-bus developers, they just say to punt. and well, if we put the system bus in the kernel and make it panic() on exit, that works around the issue | 20:01 |
| Keybuk | I don't think that's relevant though? | 20:01 |
| Keybuk | it's still a good example | 20:01 |
| Keybuk | if X crashes, we probably have to restart everything that depended on it | 20:02 |
| sadmac2 | Keybuk: if the respawn is in the state machine its a good example of the case for transition actions | 20:04 |
| sadmac2 | transition A => TryRestartA on failed($OUR_SERVICE_HANDLE) | 20:05 |
| sadmac2 | Mmm... runtime type definition | 20:52 |
| * sadmac2 loves Ruby | 20:52 | |
| ion_ | Ruby for the win. | 21:20 |
| sadmac2 | notting: what is the state of the kernelspace dbus? I was at the talk, but I hadn't slept much and was only intermittently conscious. | 21:28 |
| notting | not really that close to done | 21:29 |
| sadmac2 | hm | 21:29 |
| notting | sort of a proof-of-concept | 21:30 |
| keesj | if (dbus in kernel) then me search other job | 21:31 |
| sadmac2 | keesj: wth kind of programming language is that? Visual Caveman? | 21:32 |
| keesj | human2.0 | 21:33 |
| keesj | (based on lua) | 21:33 |
| sadmac2 | oic | 21:34 |
| keesj | well perhaps it can beat sysfs and netlink. | 21:35 |
| sadmac2 | Keybuk: I'm hitting the old question: User starts X, event says to stop it. We do ?? | 21:38 |
| sadmac2 | and its more complicated than we think | 21:41 |
| sadmac2 | stop on dont-particularly-feel-like-spending-resources-on-this // User probably takes precedence | 21:41 |
| sadmac2 | stop on disk-we-were-using-just-up-and-vanished // User can probably shove it | 21:42 |
| sadmac2 | nvm doing it wrong | 21:53 |
| Keybuk | event can't say to stop it? | 21:53 |
| Keybuk | we removed "stop on" | 21:53 |
| sadmac2 | Keybuk: yes. Just realized that | 21:54 |
| Keybuk | the condition in which X is permitted to be running can become false | 21:54 |
| Keybuk | so obviously, it has to be stopped ;) | 21:54 |
| Keybuk | the user can only start it while that is true anyway | 21:54 |
| Keybuk | when I realised we'd solved that old issue, I cried | 21:54 |
| Keybuk | with joy | 21:54 |
| sadmac2 | Keybuk: I think instead of 'until', we should just say that anywhere you can use a state name you can also say (a..b) where a and b are events | 21:55 |
| Keybuk | why is .. better than a keyword? | 21:55 |
| Keybuk | how does that work when a contains multiple parameters? | 21:56 |
| sadmac2 | (a b c .. d) | 21:57 |
| Keybuk | why is ".." better than "until" ? | 21:57 |
| sadmac2 | its better because its valid /anywhere/ a state is | 21:57 |
| sadmac2 | when foo and (a .. b) on bar | 21:57 |
| Keybuk | when foo and (a until b) on bar | 21:57 |
| sadmac2 | you can wordify it yes | 21:58 |
| sadmac2 | but that is different than on a until b | 21:58 |
| Keybuk | was from a until b | 21:58 |
| sadmac2 | you wrote on a until b on the whiteboard at one point | 21:58 |
| Keybuk | this is just syntax though | 21:58 |
| Keybuk | I'm more interested in how it works atm | 21:59 |
| sadmac2 | true | 21:59 |
| sadmac2 | Keybuk: issue with your assertion about the dependency: | 22:02 |
| sadmac2 | wait... | 22:02 |
| * Keybuk sits down and starts singing about gold | 22:03 | |
| sadmac2 | ok | 22:03 |
| sadmac2 | we're good | 22:03 |
| sadmac2 | I need to teach my brain to trust previous results | 22:03 |
| sadmac2 | after I implemented that instance hack for states in 0.5 I think I twice had to re-prove to myself that it would work | 22:04 |
| Keybuk | what was the issue? | 22:04 |
| sadmac2 | what if the user starts service A, which auto-starts its dependency service B, and then the user tries to stop service B | 22:04 |
| Keybuk | then A would stop | 22:06 |
| sadmac2 | yep | 22:06 |
| sadmac2 | actually, a nice "WARNING: YOU ARE A MORON" might be nice. | 22:06 |
| ion_ | Didn’t read the discussion yet, but such a warning is always nice. :-) | 22:08 |
| Keybuk | well, we could do quite interesting things | 22:08 |
| Keybuk | # stop apache | 22:08 |
| Keybuk | must also stop tomcat, continue? [y/n] | 22:09 |
| Keybuk | # stop -f apache | 22:09 |
| Keybuk | obviously we'd only do that if apache was making a depender's state false | 22:09 |
| Keybuk | if apache depended on tomcat, we wouldn't bug | 22:09 |
| sadmac2 | So from what I have we have 3 reasons a service can start (An event the service listens for, Dependency, or User saying go) and 2 it can stop (lost dependency, User saying stop) | 22:11 |
| Keybuk | err four | 22:12 |
| sadmac2 | what's 4? | 22:12 |
| Keybuk | dependant state becoming true, and auto | 22:12 |
| Keybuk | event while dependant state is true | 22:12 |
| Keybuk | depended on by another service while dependant state is true | 22:13 |
| Keybuk | user saying so while dependant state is true | 22:13 |
| sadmac2 | Keybuk: reason 1 and 2 are the same in the current abstraction (You'll recall epsilon events?) | 22:14 |
| sadmac2 | my terminal fails at unicode today or I'd use an actual epsilon | 22:14 |
| sadmac2 | ɛ | 22:15 |
| sadmac2 | there we go | 22:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!