| sadmac2 | Keybuk: http://screwyouenterpriseedition.blogspot.com/2008/12/new-upstart-state-machine-part-2.html | 16:11 |
|---|---|---|
| sadmac2 | ignore what you didn't understand from the last post | 16:12 |
| sadmac2 | This should be simple enough | 16:12 |
| ion_ | sadmac: Concrete examples would be easier to grasp. | 16:13 |
| sadmac2 | ion_: that's part 4 :) | 16:13 |
| ion_ | Actual use cases instead of thystate and crunchy | 16:13 |
| sadmac2 | ion_: I don't want to redesign this thing again. Part of that means that rigor is very important to me. | 16:14 |
| sadmac2 | I want this thing to be perfectly defined. Its only its /presentation/ that has to be perfectly comprehensible. | 16:14 |
| ion_ | Explaining it in a way we mere mortals understand shouldn’t require changing the design. :-) | 16:19 |
| sadmac2 | ion_: it doesn't :) | 16:19 |
| sadmac2 | ion_: but designing it in a way mere mortals understand requires changing the design every time someone says "well what about this?" | 16:19 |
| sadmac2 | ion_: the fact is mere mortals don't have to know how it works for most values of "how it works" | 16:23 |
| sadmac2 | ion_: relational databases: "put shit in tables," "Use joins" | 16:24 |
| sadmac2 | ion_: that's a piss-poor picture of the relational model, but its almost enough to not screw up with postgres | 16:24 |
| ion_ | Please give us the piss-poor picture of your design. :-) | 16:27 |
| sadmac2 | ion_: you have states. they are either on or off. they can require others to be on before they come on. they can be made to come on upon certain system events, whenever their dependencies are satisfied, or automatically. | 16:30 |
| sadmac2 | ion_: there's another process that will start a service whenever a particular state is on | 16:30 |
| Keybuk | what about the process that sets the state based on the service? | 16:32 |
| sadmac2 | Keybuk: when does that happen? | 16:32 |
| Keybuk | what else would you set states from? | 16:33 |
| sadmac2 | devicekit signals, user request, etc | 16:34 |
| sadmac2 | events | 16:34 |
| Keybuk | D-Bus signals (like those from DeviceKit) are very definitely events, not states | 16:45 |
| Keybuk | I think the most common case is dependencies on other jobs | 16:46 |
| sadmac2 | right | 16:46 |
| Keybuk | with the second most common case being the existing of particular D-Bus objects | 16:46 |
| Keybuk | (which is defined as the period between two well known events with common parameters) | 16:46 |
| sadmac2 | still with you | 16:46 |
| Keybuk | though defining D-Bus signals is just a world of ugh | 16:52 |
| sadmac2 | the split beetween Pid 1 (the service manager) and Pid X (the state machine) is what I want to firm up the most | 16:53 |
| Keybuk | from dbus(NAME=org.freedesktop.DeviceKit, PATH=/org/freedesktop/DeviceKit, MEMBER=org.freedesktop.DeviceKit.DeviceEvent, 1="add") until dbus(NAME=org.freedesktop.DeviceKit, PATH=/org/freedesktop/DeviceKit, MEMBER=org.freedesktop.DeviceKit.DeviceEvent, 1="remove", 2=$2) | 16:54 |
| sadmac2 | Keybuk: we can probably macrify a lot of that. especially for something like devicekit that we'll be hitting up all the time | 16:56 |
| sadmac2 | from US_DEVKIT(1="add") until US_DEVKIT(1="remove", 2=$2) | 16:57 |
| Keybuk | of course, that requires from/until to match the right side against the left | 16:58 |
| Keybuk | which is pretty essential | 16:58 |
| sadmac2 | Keybuk: I think we probably had it right before | 17:01 |
| Keybuk | before? | 17:02 |
| sadmac2 | Keybuk: from have_device(%1) until lost_device(%1) | 17:02 |
| Keybuk | right | 17:02 |
| sadmac2 | Keybuk: where have_device and lost device are something that is specifically sent to the state machine | 17:02 |
| Keybuk | while <STATE> -- defines a match on STATE | 17:02 |
| sadmac2 | and causing those events due to whatever is SEP | 17:02 |
| Keybuk | from EVENT until EVENT -- defines a match on a state defined as EVENT ... EVENT (rhs of a state matches against left) | 17:03 |
| Keybuk | before <STATE> -- defines a match on the opposite side of the STATE transition to while | 17:03 |
| sadmac2 | whoa. do we need that? | 17:03 |
| Keybuk | omgyes | 17:04 |
| Keybuk | while ~= started -> stopping | 17:04 |
| Keybuk | before =~ starting -> stopped | 17:04 |
| sadmac2 | oic | 17:04 |
| sadmac2 | I kind of like the idea of specifying the state names for each of these | 17:05 |
| sadmac2 | foostate while otherstate | 17:05 |
| sadmac2 | let me explain why: | 17:05 |
| Keybuk | but you're inherently specifying the state name | 17:05 |
| Keybuk | because you're writing it in the job file ;) | 17:05 |
| Keybuk | or the state definition file ;) | 17:06 |
| sadmac2 | Keybuk: that's my issue | 17:06 |
| sadmac2 | Keybuk: I want to dissociate states from files | 17:06 |
| sadmac2 | Keybuk: consider replacing runlevels. | 17:06 |
| sadmac2 | Keybuk: we have a series of states, defined however, but none of them have auto | 17:06 |
| Keybuk | I don't want to replace them, I want to kill them dead :) | 17:07 |
| sadmac2 | Keybuk: well, we need some way to group services based on what kind of system the user wants running | 17:07 |
| Keybuk | /etc/init/docked: | 17:08 |
| Keybuk | while service1 | 17:08 |
| Keybuk | while service2 | 17:08 |
| Keybuk | while service3 | 17:08 |
| Keybuk | docked is true if they're all running | 17:08 |
| Keybuk | and you can start/stop docked manually to enter/leave that state | 17:08 |
| sadmac2 | ah, damn | 17:08 |
| sadmac2 | I don't think in terms of pulling the dependencies well yet :) | 17:08 |
| Keybuk | of course, you might arguably want to separate the dependencies from the requirements | 17:09 |
| sadmac2 | Keybuk: you might want them to come from another place | 17:09 |
| sadmac2 | /etc/init/docked-foopkg: error: file not found | 17:10 |
| sadmac2 | yum install foopkg | 17:10 |
| sadmac2 | /etc/init/docked-foopkg: | 17:10 |
| sadmac2 | docked while fooservice | 17:10 |
| Keybuk | makes it hard to find out what docked is | 17:11 |
| Keybuk | you have to grep multiple trees of files | 17:11 |
| sadmac2 | Keybuk: we have to support that case somehow though | 17:12 |
| sadmac2 | Keybuk: also, that case kind of demonstrates why "while" might be a poor choice | 17:13 |
| sadmac2 | it reads "whe are docked while fooservice is running" | 17:13 |
| sadmac2 | which feels particularly backward for that state | 17:13 |
| sadmac2 | I propose "implies" | 17:13 |
| sadmac2 | docked implies fooservice | 17:13 |
| sadmac2 | brb lunch. my backlog should contain you if you keep going :) | 17:14 |
| ion_ | For that, | 17:22 |
| ion_ | /etc/init/foo: | 17:22 |
| ion_ | while docked | 17:22 |
| sadmac2 | ion_: that means the opposite | 18:20 |
| sadmac2 | ion_: that means whenever you started foo, the system would enter the docked state | 18:20 |
| ion_ | I propose it doesn’t. :-) | 18:20 |
| sadmac2 | ion_: then what goes in /etc/init/docked? | 18:21 |
| ion_ | from devicekit-said-dock-connected until devicekit-said-dock-disconnected | 18:22 |
| sadmac2 | ion_: so foo gets while foo; auto | 18:26 |
| ion_ | Huh? | 18:28 |
| sadmac2 | ion_: while docked; auto | 18:39 |
| sadmac2 | ion_: sorry | 18:39 |
| sadmac2 | hmm... a implies a | 18:39 |
| sadmac2 | how do tautological states behave? | 18:39 |
| ion_ | What’s this auto thing? | 18:40 |
| sadmac2 | ion_: a state doesn't start just because its deps are satisfied unless auto is specified | 18:40 |
| sadmac2 | ion_: otherwise its deps satisfied + got event | 18:40 |
| sadmac2 | The more I describe this state machine the more I realize its a great deal more powerful than I thought :) | 20:01 |
| sadmac2 | Its can do some things I didn't think of | 20:01 |
| sadmac2 | mount_state(dev: %1, mountpoint: %2) { action: mount $dev $mountpoint } | 20:04 |
| sadmac2 | ^^ignore that... | 20:04 |
| sadmac2 | mount_state(dev: %1, mountpoint: %2, type: %3) { action: mount -t $type $dev $mountpoint } | 20:05 |
| sadmac2 | mount_state(dev: %1, mountpoint: %2, type: funkyfusefs) { action: funkyfusemounter $dev $mountpoint } | 20:05 |
| sadmac2 | its like haskell, but in a good way | 20:07 |
| sadmac2 | ion_, Keybuk: http://screwyouenterpriseedition.blogspot.com/2008/12/new-upstart-state-machine-part-3.html | 21:44 |
| sadmac2 | ^^practical examples included (start reading when you see fstab lines) | 21:45 |
| === mbiebl_ is now known as mbiebl | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!