| === cortana [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart | ||
| === wasabi_ [n=wasabi@cpe-76-184-122-13.tx.res.rr.com] has joined #upstart | ||
| === MasseR [n=masse@dsl-tkubrasgw1-fe11fa00-85.dhcp.inet.fi] has joined #upstart | ||
| === Keybuk [n=scott@quest.netsplit.com] has joined #upstart | ||
| AlexExtreme | trying to code shortly after you wake up never works too well | 10:01 |
|---|---|---|
| Keybuk | morning | 10:09 |
| Keybuk | yeah I find that | 10:09 |
| AlexExtreme | i'm trying to work on this profiles code and my brain just says "uhh?" :p | 10:10 |
| Keybuk | have a bananananana :p | 10:12 |
| AlexExtreme | :D | 10:12 |
| AlexExtreme | oh well, bbl | 10:19 |
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| === Keybuk tackles the problem of namespace collision | ||
| Keybuk | too many structs :-/ | 12:08 |
| Keybuk | conf_sources -(hash)-> ConfSource -(hash)-> ConfFile -(list)-> ConfItem -> job/state/etc. | 12:08 |
| Keybuk | to track names, I'd need | 12:08 |
| Keybuk | namespace -(hash)-> Name -(list-> job/state/etc. | 12:08 |
| Keybuk | http://people.ubuntu.com/~scott/conf.jpg | 12:35 |
| Keybuk | :-( | 12:35 |
| === Keybuk wonders whether objects of different types should share namespaces | ||
| Keybuk | e.g. should states and jobs share a namespace? | 12:39 |
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| === sadleder [n=sadleder@p50813612.dip0.t-ipconnect.de] has joined #upstart | ||
| === sadleder [n=sadleder@p50813612.dip0.t-ipconnect.de] has left #upstart [] | ||
| === sadleder [n=sadleder@p50813612.dip0.t-ipconnect.de] has joined #upstart | ||
| === sadleder [n=sadleder@p50813612.dip0.t-ipconnect.de] has left #upstart [] | ||
| === asdaf [n=Ack@213-140-11-128.fastres.net] has joined #upstart | ||
| === tale [n=tale@207.235.54.1] has joined #upstart | ||
| === ion_ [i=ion@heh.fi] has joined #upstart | ||
| wasabi | states and jobs? | 04:10 |
| wasabi | states are jobs, no? | 04:10 |
| Keybuk | no | 04:11 |
| wasabi | you mean something other than what I was thinking you did, then | 04:11 |
| Keybuk | an example of a state is the period between tty-added and tty-removed for the same $TTY | 04:12 |
| Keybuk | this state can have multiple concurrent instances, since you can have multiple $TTYs | 04:12 |
| wasabi | Hmm. This is all getting very confusing. I like dit when you needed one file per tty. :0 | 04:12 |
| wasabi | It made the idea of a state easy: while job-name | 04:13 |
| Keybuk | heh | 04:20 |
| Keybuk | I like the idea of one file for all ttys | 04:20 |
| Keybuk | since they're identical | 04:20 |
| === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart | ||
| === phoenix24 [i=shp@ns38066.ovh.net] has joined #upstart | ||
| wasabi | Just being identically doesn't make it automatically a case to combine. | 05:43 |
| wasabi | identical | 05:43 |
| wasabi | What was wrong with our initial idea of jobs themselves defining named states? | 05:43 |
| Keybuk | doesn't work for the tty case | 05:44 |
| wasabi | Actually, I guess I don't really even know what I'm talking about anymore. Ya'll have probably done a lot of work since I was last in on it. | 05:44 |
| Keybuk | or the network interface case | 05:44 |
| Keybuk | it works on paper, but not for the use cases it's actually needed for | 05:45 |
| wasabi | Explain the tty case? | 05:45 |
| Keybuk | network interface is less controversial, so let's use that as an example | 05:45 |
| wasabi | Okay, that. ;0 | 05:45 |
| Keybuk | we have a pair of events with a common variable | 05:45 |
| Keybuk | interface-up eth0 | 05:45 |
| Keybuk | interface-down eth0 | 05:45 |
| Keybuk | so we can define the pairing and name that, say, interface-is-up | 05:45 |
| Keybuk | interface-up ... interface-down $IFACE | 05:46 |
| Keybuk | so when any interface comes up, the state is true | 05:46 |
| Keybuk | and when that same interfaces goes down, the state becomes false | 05:46 |
| Keybuk | ok? | 05:46 |
| wasabi | ok. | 05:46 |
| Keybuk | computers have multiple interfaces | 05:46 |
| Keybuk | we don't just want to track the first one that we see, we want to track them all | 05:47 |
| Keybuk | so when we see "interface-up lo", the state is true "for lo" | 05:47 |
| Keybuk | we might next see "interface-up eth0", now the state is true "for lo" and "for eth0" | 05:47 |
| Keybuk | next we might see "interface-down eth0" | 05:47 |
| Keybuk | this only matches the second half of the "for eth0" true state, so that state becomes false | 05:47 |
| Keybuk | now the state is only true "for lo" | 05:47 |
| Keybuk | by thinking in this way, we can answer the questions | 05:48 |
| Keybuk | is the state true for any interface (any network interface is up!) | 05:48 |
| wasabi | I'd start with a network job, which only started when Any interfaces were up, and stopped itself when the last interface went down. You can then depend on the start/stopped of that job to define a state where any interaface is up. | 05:48 |
| Keybuk | is the state true for a specific interface (or any non-lo interface) | 05:48 |
| Keybuk | wasabi: but that involves defining a job that tracks the up/down events it receives, no? | 05:49 |
| wasabi | Yes, it does. | 05:49 |
| Keybuk | how would you define a job that was running while any interface, apart from lo, was up? | 05:49 |
| wasabi | It would start on any interface up, and stop on any interface down. And the pre-stop handler would check if ALL interfaces were down, if not, it wouldn't really stop. | 05:49 |
| wasabi | In code. | 05:50 |
| Keybuk | the nice things about having first-class states is that you don't need to do that | 05:50 |
| Keybuk | upstart can track that for you | 05:50 |
| Keybuk | in fact, we then get to do things like | 05:50 |
| Keybuk | "is the set of paths that are mounted a subset of the following list?" | 05:50 |
| Keybuk | so upstart itself can track the problem of the writable filesystem | 05:50 |
| wasabi | interesting. | 05:51 |
| wasabi | Not sure if that's completely beneficial to implement that way or not. The script thing, as far as I can tell, works. | 05:51 |
| Keybuk | jobs implicitly have a state coupled to them | 05:52 |
| Keybuk | so by defining a job, you are also defining the state which defines when they are running | 05:52 |
| Keybuk | but I figured that since the machine is sufficiently useful, one should be able to define states in their own right, for use in the definitions of other jobs | 05:52 |
| Keybuk | the /etc/init/conf.d/udev example holds here; where udev ships a rule that calls initctl for appropriate events, and ships upstart states for each of the event pairs | 05:53 |
| Keybuk | so a job doesn't have to worry about module-loaded ... module-removed | 05:53 |
| Keybuk | you could do this simply by defining jobs for them all | 05:54 |
| Keybuk | but they would have to be all instance jobs | 05:54 |
| wasabi | All the modules? Not worth it. They are very situation specific. | 05:54 |
| Keybuk | (an alternative viewpoint is to make all jobs instance jobs by default :p) | 05:54 |
| wasabi | Why is from module-loaded foo to module-removed foo so bad? | 05:55 |
| wasabi | Ya know, another thing I'm concerned about in all of this is starting a job midstream. What if you install the job file while the foo module is loaded, does it sit there waiting for foo to show up? | 05:56 |
| wasabi | Or are you going to always model all system state in upstart at all times? | 05:56 |
| wasabi | I don't think so. I think you'd install the job, and ask it to start, right now. And it would check if the module was loaded, in pre-start. | 05:56 |
| wasabi | And this is all weird anyways because it's inherently race. You can never guarentee that the module didn't remove itself after the job was started. | 05:57 |
| wasabi | s/race/racey/ | 05:57 |
| wasabi | So every job still has to verify that the system is proper, it has to check if the module is loaded. | 05:57 |
| wasabi | So inevitably each script will have sanity checks in pre-start. Regardless how much help upstart gives it. | 05:58 |
| wasabi | All of this together makes me wonder if it's not getting just too complicated. | 06:03 |
| wasabi | Maybe I'm just being negative today. | 06:06 |
| wasabi | You could do network interfaces like that today. | 06:08 |
| wasabi | interface-up job which fires when udev tells it an interface is up. It can itself main some state files in /var/run or something. | 06:08 |
| Keybuk | believe it or not, this way is simpler to implement than having raw jobs as states | 06:08 |
| wasabi | And it can keep track itself what interfaces are or are not up... and emit events for specific interfaces. | 06:09 |
| Keybuk | I think that services will almost always describe the states in which they should be running, rather than being directly event based | 06:09 |
| wasabi | hmm | 06:09 |
| Keybuk | ie. "while there is a network interface up, and the filesystem is writable, and dbus is running" | 06:09 |
| Keybuk | if true, the state graph can be evaluated when the job is created, so yes, it would start automatically | 06:10 |
| Keybuk | it is inherently racey, so the service should fail normally if the resources it expects are not available | 06:10 |
| wasabi | It can only be evaluated if the state which is defined by events is installed before those events happen. | 06:10 |
| Keybuk | (this is not unreasonable) | 06:10 |
| wasabi | No? | 06:10 |
| Keybuk | right, that is true in the current upstart model | 06:11 |
| Keybuk | upstart would need to record all events to avoid that | 06:11 |
| wasabi | Yeah, and that's probably unreasonable. | 06:11 |
| wasabi | So, somebody is still going to have to, after installing a new job with a new state, give it a push. | 06:11 |
| wasabi | Write some code which checks if the state is true by evaluating the system. | 06:11 |
| Keybuk | I think it will be rare that this is true, no? | 06:12 |
| === mbiebl [n=michael@e180071063.adsl.alicedsl.de] has joined #upstart | ||
| wasabi | I'm not sure. | 06:12 |
| Keybuk | jobs that should be started in postinst will rarely need to define a state based on events | 06:12 |
| Keybuk | but yes, that is a concern | 06:12 |
| Keybuk | there's more interesting examples | 06:12 |
| wasabi | But if those states were maintained by stateless jobs, it's not a concern. | 06:12 |
| Keybuk | ? | 06:13 |
| wasabi | So you have a network job, which fires anytime a network interface, any interface, comes up or down. It keeps a count in /var someplace about the total number of active interfaces, by actually checking the interfaces, not reading the events. | 06:13 |
| Keybuk | ok | 06:14 |
| mbiebl | Keybuk: hi | 06:14 |
| wasabi | And a job which cares about the network would need to start on any network event also, and check that file. Or something. | 06:14 |
| wasabi | I don't know. | 06:14 |
| wasabi | Which is still racey. | 06:14 |
| Keybuk | the same network-monitoring job could register the states in upstart's memory directly | 06:14 |
| wasabi | It would have to check itself. | 06:14 |
| Keybuk | avoiding the use of filesystems | 06:14 |
| wasabi | But then we're just talking about reusable scripts. | 06:14 |
| Keybuk | fiddly scripts :) | 06:15 |
| wasabi | Explain how states in upstart are maintained? | 06:15 |
| wasabi | It makes me wonder if what is being built doesn't actually solve any issue, is all. | 06:16 |
| wasabi | Since hte issue is still there. | 06:16 |
| Keybuk | what issue do you think we're attempting to solve? | 06:16 |
| wasabi | Every job that cares about network has to actually check the network and exit gracefully in pre-start. | 06:16 |
| Keybuk | why pre-start? | 06:16 |
| wasabi | Or start. | 06:17 |
| Keybuk | it can exit ungracefully in main | 06:17 |
| wasabi | True, you are correct, but still, every job has to do that. | 06:17 |
| Keybuk | and log in syslog that it was unable to bind to the interface | 06:17 |
| Keybuk | *shrug* every job does that already if it's checking the return codes of its syscalls like a good daemon | 06:17 |
| wasabi | Yup. | 06:17 |
| mbiebl | Keybuk: I've got two questions. | 06:17 |
| wasabi | So, by recording states, at all, in upstart or otherwise, what are you solving? They may be recorded in upstart, but jobs still have to check on their own properly. | 06:17 |
| wasabi | So why not just let jobs do that? | 06:18 |
| Keybuk | wasabi: solving the reattempt to start the job issue | 06:18 |
| mbiebl | First: Is the Ubuntu udev patched to create /dev/console,null and the std* symlinks? | 06:18 |
| Keybuk | the job doesn't just have to check it, it has to accept all possible states can fail intermittently, and fallback to some kind of "waiting for appropriate state" inner loop | 06:19 |
| Keybuk | if it cannot bind() to the interface, it has to loop until it can | 06:19 |
| wasabi | But doesn't the job have to reeveluate that in that loop on EVERY event that might contribute to the state? | 06:19 |
| Keybuk | perhaps with some kind of asynchronous notification from an interface daemon that a new interface is up, to reattempt the bind | 06:19 |
| Keybuk | exactly | 06:19 |
| Keybuk | this is the launchd model, btw | 06:20 |
| wasabi | Well, no. If it can't bind, it dies. And starts again next time something that might make it work appears. | 06:20 |
| wasabi | Yeah, I know. | 06:20 |
| Keybuk | no | 06:20 |
| Keybuk | it doesn't start again | 06:20 |
| Keybuk | because nothing will restart it | 06:20 |
| Keybuk | it failed, bad bad job | 06:20 |
| Keybuk | what upstart provides is that loop | 06:20 |
| Keybuk | the job defines what state it likes | 06:20 |
| wasabi | Eh? If it's waiting for both the file system and network, if any of those happen, it will restart. | 06:20 |
| Keybuk | and upstart guarantees that it will attempt to start the job every time the system is in that state | 06:20 |
| Keybuk | and that it will kill the job when the system goes out of that state | 06:20 |
| wasabi | And check to see if both conditions are acceptable. So, when the file system comes up, it will start and look for the network. No network? Okay die. Network comes up a few minutes later and it starts again. Checks again and starts successfully. | 06:21 |
| === phoenix24 [i=doy@ns38066.ovh.net] has joined #upstart | ||
| Keybuk | it cannot guarantee that the state will remain true for any period after the initial "this is true" | 06:21 |
| Keybuk | but it can guarantee that the job will be killed again if it hasn't noticed | 06:21 |
| Keybuk | *and* it guarantees that the job will be restarted if the state should become true again | 06:21 |
| Keybuk | wasabi: sorry, I appear to have confused you | 06:21 |
| wasabi | Perhaps. | 06:21 |
| wasabi | I confuse easily these days. | 06:21 |
| Keybuk | wasabi: my initial description of the looping application is the upstart-less world | 06:21 |
| wasabi | I think my brain has been leaking a lot lately. | 06:21 |
| Keybuk | the launchd model: | 06:22 |
| Keybuk | - all jobs are started immediately | 06:22 |
| Keybuk | - if a resource the job needs is not available, the job should sleep until it is available | 06:22 |
| Keybuk | - if a resource the job needs becomes unavailable, the job should sleep until it is available again | 06:22 |
| ion_ | As far as ive understood what Keybuk has been describing, it sounds good. | 06:23 |
| Keybuk | ie. monitor your syscalls, if any fail due to an error (bind fails, write fails, etc.) you should fall into a kind of slumber loop | 06:23 |
| Keybuk | how you wake yourself up from that slumber loop is anyone's guess | 06:23 |
| Keybuk | asynchronous notification of the potential availability of resources? | 06:23 |
| Keybuk | or maybe you just use blocking writes and blocking binds? :p | 06:23 |
| wasabi | Ya know, I don't really mind that model, except for the wake up part. | 06:23 |
| wasabi | But upstart has the wakeup part, in events. | 06:23 |
| Keybuk | right | 06:23 |
| wasabi | So slumber, but get poked when an event happens. | 06:24 |
| Keybuk | so what upstart provides is the acceptance of the reality that states come and go | 06:24 |
| wasabi | Where slumber == "just exit and let upstart start you again later" | 06:24 |
| Keybuk | it guarantees that you'll be started when the state is true, and stopped when it becomes false | 06:24 |
| Keybuk | so you can assume that any failure to obtain resources is bad, and just exit(1) | 06:24 |
| Keybuk | because you'll get restarted again next time you can have a go | 06:24 |
| wasabi | Except that those states are inherently hard to monitor, and can't be relied upon anyways. | 06:24 |
| Keybuk | states are easy to monitor | 06:25 |
| wasabi | Since they might be untrue by the time you get around to actually running. | 06:25 |
| mbiebl | Keybuk: What for ressources that upstart can't easily monitor? | 06:25 |
| Keybuk | and can be relied on to be true | 06:25 |
| Keybuk | sure, they can become false again | 06:25 |
| Keybuk | upstart says it will stop you if that happens | 06:25 |
| Keybuk | ok, you might hit the failure first, but the worst thing there is a syslog entry | 06:25 |
| mbiebl | E.g. remote services that are required, e.g. tomcat requiring a remote sql service. | 06:25 |
| Keybuk | but you *will* get restarted next time the state is true for a while | 06:26 |
| wasabi | mbiebl: I really don't think upstart offers anything there. You'd want tomcat and the database to be started independently of ech other... as there might be tomcat services that don't need the database. | 06:26 |
| Keybuk | apps become "just assume that syscalls should work, check the return value, and bail out if they don't" | 06:26 |
| Keybuk | upstart takes care of restarting you when the state is true again | 06:26 |
| wasabi | Well, okay. Yeah. I like that... but that's how it is without upstart monitoring states too. | 06:26 |
| mbiebl | Well, how is upstart supposed to know the state "remote sql service available" | 06:27 |
| mbiebl | My point is, there are states, that upstart can't provide. | 06:27 |
| wasabi | mbiebl: It's not. You'd have to implement something which feeds that state to upstart. | 06:27 |
| wasabi | Keybuk: apps can function in the maner you describe whether upstart watches states or not. Since upstart *will* start it again when any event happens that might make it runnable. | 06:28 |
| Keybuk | ah | 06:28 |
| Keybuk | upstart doesn't *monitor* states | 06:28 |
| Keybuk | upstart just provides a state whiteboard for everything else | 06:28 |
| Keybuk | e.g. heartbeat could do it for the remove case | 06:29 |
| Keybuk | remote case | 06:29 |
| Keybuk | or monit | 06:29 |
| Keybuk | or whatever | 06:29 |
| Keybuk | they just emit events which upstart can combine into states | 06:29 |
| Keybuk | or can set states true/false directly | 06:29 |
| Keybuk | (registered through the usual initctl/libupstart layer) | 06:29 |
| wasabi | Hmm. You can set states. | 06:29 |
| Keybuk | I don't see why not | 06:29 |
| wasabi | Okay, so a postinst script should set appropiate states. | 06:29 |
| wasabi | That solves that. | 06:29 |
| wasabi | A new state, for instance. | 06:30 |
| Keybuk | postinsts for new things might end up having some kind of udevtrigger-a-like | 06:30 |
| Keybuk | in fact, since many deviceish states will come with udev and HAL, udevtrigger is all you'd run :p | 06:30 |
| wasabi | postinst: "hi upstart, I know this state is valid from x to y and n to m, but I just checked x and n, and it's good. So set it right now." | 06:30 |
| Keybuk | right | 06:30 |
| Keybuk | initctl set wibble true | 06:31 |
| wasabi | So actually, a postinst for a new job might in fact set all states for that job to true without checking. | 06:31 |
| Keybuk | mbiebl: remote services should be easy with heartbeat or monit | 06:31 |
| wasabi | And the job might fail. But that's okay. | 06:31 |
| Keybuk | wasabi: or it could just "start" the job *shrug* | 06:31 |
| wasabi | Well, if it starts the job, and the job exits, the might might want to be started again properly. | 06:32 |
| wasabi | Even though events that contribute to the state the job cares about aren't set. | 06:32 |
| Keybuk | mbiebl: A to question 1 -- ubuntu's udev copies /lib/udev/devices into /dev before starting, that directory contains the usual console, null, etc. devices | 06:32 |
| wasabi | I am jumbling all my words. I have no idea why I do that. | 06:32 |
| wasabi | Let me try again. | 06:32 |
| mbiebl | Keybuk: Well, you'd still have to patch heartbeat to emit upstart events. | 06:32 |
| wasabi | job: from X to Y and N to M. The postinst runs. Currently X is true and N is false, but upstart doens't yet know. So the postinst starts the job. The job exits because N is false (syscall fails). N becomes true, but since X isn't yet known, the job doesn't start again. | 06:34 |
| wasabi | Hence the postinst has to set X and N to the proper values at the time of being installed, and let new events from that point on alter them. | 06:34 |
| Keybuk | yeah | 06:35 |
| Keybuk | postinsts for packages registering new states, or jobs that use unique states, should make an effort to check whether the requisites are true and set the state accordingly | 06:36 |
| wasabi | And what sets the state? | 06:36 |
| Keybuk | e.g. a package installing a state that says whether users are logged in should perhaps look at utmp | 06:36 |
| wasabi | In the normal case? | 06:36 |
| Keybuk | in the normal case, the state would be set by the daemon or by events | 06:36 |
| wasabi | Where are teh events for the state defined? | 06:37 |
| wasabi | And are states binary? | 06:37 |
| Keybuk | by some daemon or other? | 06:37 |
| wasabi | Hmm. I mean for, like the network interface case. | 06:37 |
| wasabi | Who watches the interfaces and sets the states? | 06:37 |
| Keybuk | not quite following | 06:37 |
| Keybuk | whoever installs the postinst | 06:38 |
| Keybuk | upstart does no watching | 06:38 |
| Keybuk | network interface case => udev | 06:38 |
| Keybuk | or maybe Network Manager | 06:38 |
| Keybuk | I can't remember whether that one comes via udev, HAL or NM | 06:38 |
| Keybuk | but it does come from one of them :p | 06:38 |
| wasabi | So udev essentially runs initctl set network-up $IFACE true/false? | 06:38 |
| wasabi | Or are the states defined in a file which contains `from X to Y`? | 06:39 |
| Keybuk | either is valid | 06:39 |
| Keybuk | in the udev case, I would have it emit events | 06:39 |
| Keybuk | (in fact, I think events are generally preferred) | 06:40 |
| wasabi | So oddly enough, states are back to being exactly what a job is: started or stopped, true or false. :0 | 06:40 |
| wasabi | Just without any executable. | 06:40 |
| Keybuk | yes | 06:41 |
| Keybuk | the implementation is very closely coupled internally | 06:41 |
| Keybuk | in fact, all jobs have a state associated with them | 06:41 |
| Keybuk | since it's that state that causes them to be started or stopped | 06:41 |
| Keybuk | the difference in definition is simply that one has more options than the other | 06:41 |
| wasabi | Hmm. I see. | 06:41 |
| wasabi | So, you might in fact have a state and a job file both in /etc/event.d. Both files would look about the same, except the state one wouldn't have any exec lines. | 06:42 |
| wasabi | And why the syntax difference between 'set' and 'start/stop' in initctl? | 06:42 |
| Keybuk | that's the bit I'm trying to work out now :) | 06:42 |
| Keybuk | whether it is worth exposing the internal difference externally | 06:43 |
| ion_ | Are states going to go to a separate directory than jobs according to the current plan? | 06:43 |
| wasabi | Well, if jobs are internally states... | 06:43 |
| wasabi | Then they belong in the same dir. | 06:43 |
| Keybuk | and if the difference isn't exposed, how do we avoid the bloat of every state carrying the entire Job structure with it? | 06:43 |
| wasabi | Are we talking about /etc/state.d? :0 | 06:43 |
| Keybuk | /etc/init | 06:43 |
| ion_ | /etc/init/{job.d,state.d}? | 06:43 |
| wasabi | Keybuk: Well, you have a set of states, and a set of jobs. | 06:44 |
| wasabi | Jobs depend on states. There is no external visibility of a job, except for the various running executables. | 06:44 |
| Keybuk | jobs show up in initctl list | 06:44 |
| wasabi | initctl stop foo actually means "set state `foo` to false", which internally results in the job structure going through the lifecycle for termination. | 06:44 |
| Keybuk | should states? | 06:44 |
| wasabi | Perhaps. | 06:44 |
| ion_ | Im in favour of putting jobs and states to separate directories. When there are going to be a lot of files in the directories, it will be helpful. | 06:45 |
| Keybuk | ion_: then you have namespace collision issues | 06:45 |
| wasabi | I'd not put them in seperate directories because it will intrduce some confusion. If a job is a state... then a job can depend on another job. | 06:45 |
| wasabi | But also on a state. | 06:46 |
| wasabi | Because there is no difference. | 06:46 |
| wasabi | So if a job depends on `foo`, go find foo. | 06:46 |
| Keybuk | there is a difference at the moment | 06:46 |
| Keybuk | states are instantiable by default | 06:46 |
| Keybuk | jobs aren't | 06:46 |
| wasabi | Anyways, we've come full circle again. Back to jobs being exactly the same as states. There being no real internal difference except one has a structure for process lifecycle management. | 06:47 |
| Keybuk | which is where it becomes interesting | 06:47 |
| Keybuk | because if the lifecycle management can be separated, then we get to interesting ideas | 06:47 |
| Keybuk | for example, imagine you have a state for the existance of a particular file | 06:48 |
| Keybuk | tied into inotify maybe | 06:48 |
| wasabi | ECOMPREHEND | 06:48 |
| Keybuk | jobs could be run while and for /etc/site/*/apache.conf | 06:48 |
| Keybuk | in other words, one copy of the job is run for each of the files that exists | 06:48 |
| wasabi | That is interesting. | 06:49 |
| wasabi | state---<job | 06:49 |
| wasabi | Or, not really. | 06:49 |
| wasabi | Is that one state or many states? heh | 06:49 |
| wasabi | Well, it's one state... effected by many files. | 06:49 |
| wasabi | affected | 06:49 |
| wasabi | where each file defines a job structure hanging off the state. | 06:49 |
| wasabi | When using the inotify/glob thing you just said, what is the value of the state at any time? | 06:50 |
| Keybuk | true for a given filename | 06:51 |
| wasabi | But when does it become false? | 06:51 |
| Keybuk | states can have one false value, or one or more truths | 06:51 |
| Keybuk | when there are no trues | 06:51 |
| wasabi | Well, inotify is an event that says the file was altered. There is no correspondening point in time that the file "is not altered". | 06:51 |
| Keybuk | not 100% sure about this bit yet | 06:52 |
| wasabi | So it doesn't form a timeline of any sort. | 06:52 |
| Keybuk | with inotify, we know when the file exists, when it is deleted and when it is modified | 06:52 |
| Keybuk | so you put create on the left of the state | 06:52 |
| Keybuk | delete on the right of the state | 06:52 |
| Keybuk | and put modify on both sides, so the job is restarted | 06:52 |
| wasabi | So while the file exists? | 06:52 |
| wasabi | Ahh. | 06:53 |
| Keybuk | the part of upstart that supplies this notification would set the states on startup using stat() | 06:53 |
| wasabi | And now you have a true/false state that actually means file existance, but it toggles when it's modified. | 06:53 |
| wasabi | But you can't detect the toggle, you can just see the fall out from it. | 06:53 |
| Keybuk | right | 06:53 |
| Keybuk | you may be more discreet, and define a file-exists state, and a file-same state or something | 06:53 |
| Keybuk | so the job can choose | 06:53 |
| wasabi | This could be implemented outside of upstart as well, in a way. | 06:55 |
| wasabi | Which might be ... better? | 06:55 |
| wasabi | Upstart only knows of the state. A seperate runnable daemon watches the files and toggles the states. | 06:55 |
| wasabi | An extremely simple daemon. | 06:56 |
| Keybuk | right | 07:00 |
| Keybuk | my theory is that upstart would be able to supply the answer to a request of "what arguments to the file-created event are states expecting?" | 07:00 |
| Keybuk | so the daemon would register that it supplies that event | 07:01 |
| Keybuk | and upstart would respond with the arguments that it knows, and with new ones as jobs are created | 07:01 |
| Keybuk | so the daemon knows what to watch | 07:01 |
| Keybuk | this is all my next thing to tackle, anyway | 07:10 |
| Keybuk | now that the config code is better | 07:10 |
| === phoenix24_ [i=hemvy@ns38066.ovh.net] has joined #upstart | ||
| AlexExtreme | porting the profile code to the new config stuff is harder than I would have liked ;) | 08:20 |
| wasabi | Now, what do profiles do? | 08:20 |
| wasabi | I think I missed that conversation. | 08:20 |
| AlexExtreme | http://upstart.ubuntu.com/wiki/Profiles | 08:21 |
| AlexExtreme | (this code isn't in main, it's in my branch) | 08:21 |
| wasabi | ahh | 08:21 |
| === phoenix24 [i=pgsgrhq@ns38066.ovh.net] has joined #upstart | ||
| wasabi | Seems simple, reasonable, and sane. | 08:23 |
| AlexExtreme | cool | 08:23 |
| wasabi | ie not a huge subsystem, just a simple filter of state names. | 08:23 |
| wasabi | at uds-mtv we talked about some sort of flag thing which you could set, and instead of using profiles (something outside of the job) to determine whether the job would run, the job itself would check the flag. | 08:23 |
| === wasabi shrugs. | ||
| AlexExtreme | yeah | 08:24 |
| wasabi | Which could interestingly enough be done with states. | 08:24 |
| AlexExtreme | i didn't particularly like that idea for some reason which i can't remember | 08:24 |
| wasabi | where states were settable from the loader prompt. | 08:24 |
| AlexExtreme | bbl | 08:28 |
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| === Keybuk [n=scott@quest.netsplit.com] has joined #upstart | ||
| Keybuk | an interesting thought has occurred | 09:21 |
| Keybuk | the state in which the apache job can be run | 09:21 |
| Keybuk | is not the same as | 09:21 |
| Keybuk | the state in which the apache job is running | 09:23 |
| === juergbi [n=juerg@80-219-16-162.dclient.hispeed.ch] has joined #upstart | ||
| wasabi | Hmm. I barely understand that. | 09:44 |
| === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart | ||
| === cortana [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
