| sadmac | Keybuk: and it "belongs" in /usr/apache/conf if upstream has their sya | 00:00 |
|---|---|---|
| sadmac | *say | 00:00 |
| Keybuk | oh, that's right, you guys rename it for some inexplicable reason | 00:00 |
| sadmac | Keybuk: so do you. | 00:00 |
| Keybuk | we call it apache2 | 00:01 |
| sadmac | yep. Its not supposed to be. | 00:01 |
| sadmac | its supposed to just be apache, and (scarier) its not supposed to be in etc | 00:01 |
| Keybuk | ok, true, it should be apache | 00:01 |
| Keybuk | but apache is apache 1.x | 00:01 |
| sadmac | Keybuk: the plot thickens... | 00:02 |
| sadmac | Keybuk: at any rate, its already getting ugly this idea of distro-compatible scripts | 00:02 |
| sadmac | Keybuk: if you force them to be in one file, you are going to see people do things with sed that you can't unsee | 00:03 |
| sadmac | in package post-install scripts | 00:03 |
| mbiebl | sadmac: I think simple/trivial scripts could surely be cross-distro | 00:04 |
| mbiebl | acipd, smartd, | 00:04 |
| mbiebl | atd ... | 00:04 |
| sadmac | mbiebl: well they're welcome to, but we aren't talking about simple, trival scripts. We're talking about /all/ scripts | 00:05 |
| sadmac | this is blanket policy | 00:05 |
| Keybuk | things have to be upstream | 00:05 |
| Keybuk | because if they're not upstream, then we have to maintain them as a divergence from Debian | 00:05 |
| Keybuk | and that hurts | 00:05 |
| Keybuk | if they're uniform, then upstream can put them in the tarball | 00:05 |
| Keybuk | and Debian takes Upstart through the back door | 00:05 |
| sadmac | someone's going to be taking it through the back door alright :) | 00:06 |
| sadmac | I don't think it will happen | 00:06 |
| sadmac | even still, I think the python syntax will make more sense anyway with the new state machine | 00:07 |
| Keybuk | depends | 00:07 |
| Keybuk | I actually have a vague theory about being able to specify multiple things in one file | 00:07 |
| Keybuk | like if you're defining apache, you should be able to put the daily log rotation job in there too | 00:08 |
| Keybuk | so one bit defines the daemon, then you define a different while/on clause, with a different task/service attached | 00:08 |
| sadmac | Keybuk: the way it is now, you could have: | 00:08 |
| sadmac | foostate(bar: baz): | 00:08 |
| sadmac | when something | 00:08 |
| sadmac | foostate(bar: bang): | 00:08 |
| sadmac | when something else | 00:08 |
| sadmac | Keybuk: and those conf items could apply to two different states /or both apply to the same state/ | 00:09 |
| sadmac | Keybuk: foostate(bar: baz) will get the first when, foostate(bar: bang) gets the second, foostate(bar: baz, bar: bang) gets both | 00:09 |
| ion_ | Real-life examples would be so much nicer. :-) | 00:10 |
| sadmac | ion_: there's actually a good IRL one in the blog posts for this particular case | 00:11 |
| sadmac | mount(...): | 00:11 |
| sadmac | (mount stuff here) | 00:11 |
| sadmac | mount(type: nfs, ...): | 00:11 |
| sadmac | when network | 00:11 |
| sadmac | mount(type: somefusefilesystem, ...): | 00:11 |
| sadmac | (non-standard mount command used) | 00:11 |
| ion_ | Much better. :-) | 00:12 |
| sadmac | the stuff under the first mount line applies to /all/ mounts. | 00:12 |
| sadmac | the latter two apply only to mounts of a particular filesystem type | 00:12 |
| Keybuk | though that optimises the uncommon case again | 00:15 |
| sadmac | Keybuk: its not terribly expensive | 00:16 |
| Keybuk | assert ( cost == 0 ); | 00:17 |
| sadmac | Keybuk: the reason I allow the state machine to behave this way is because it would cost me extra effort not to. I'd have to explicitly state it was impossible. | 00:17 |
| sadmac | cost < 0 | 00:17 |
| Keybuk | err | 00:17 |
| Keybuk | I only care about the cost to a user | 00:17 |
| Keybuk | like I said, we're writing an init daemon here | 00:18 |
| Keybuk | not a math paper | 00:18 |
| sadmac | in terms of implementation details its easier to write | 00:18 |
| Keybuk | if the implementation is harder, but gives a better user experience, I'd rather go with the harder implementation | 00:18 |
| sadmac | I see this only as a gain | 00:18 |
| sadmac | I see no disadvantage other than semantics of files, which I have no interest in preserving | 00:19 |
| Keybuk | it makes the files harder to understand | 00:19 |
| Keybuk | you need to know more about what's going on under the hood | 00:19 |
| Keybuk | you can't just do | 00:19 |
| Keybuk | cat > /etc/init/some_service | 00:20 |
| Keybuk | while ... | 00:20 |
| sadmac | It looks pretty obvious to me | 00:20 |
| Keybuk | exec ... | 00:20 |
| Keybuk | ^D | 00:20 |
| sadmac | this is what you do to mount a filesystem | 00:20 |
| sadmac | this is what's different if its nfs | 00:20 |
| sadmac | this is what's different if its a funky filesystem | 00:20 |
| Keybuk | but it isn't obvious | 00:20 |
| Keybuk | what the hell is the stuff before the : | 00:20 |
| Keybuk | is that the while clause? | 00:20 |
| sadmac | name of state, arguments to state | 00:20 |
| Keybuk | while ...: | 00:20 |
| Keybuk | ... | 00:20 |
| Keybuk | exactly, you suddenly force everyone to define a state to define a service | 00:20 |
| Keybuk | I don't like that | 00:21 |
| sadmac | if jobs /are/ states, that's kind of inherent | 00:21 |
| Keybuk | let's use a simple example then | 00:26 |
| Keybuk | how would you define the job for the dbus session bus daemon? | 00:26 |
| sadmac | dbus_session_daemon(%session): | 00:26 |
| Keybuk | it runs for each instance of the x-session state | 00:27 |
| sadmac | when x-session(id: %session) | 00:27 |
| sadmac | auto | 00:27 |
| sadmac | exec /usr/bin/dbus-session | 00:27 |
| Keybuk | ok | 00:27 |
| Keybuk | instead of exec, use eval - that puts the $DBUS_SESSION_BUS_ADDRESS into the job's environment | 00:28 |
| Keybuk | that environment variable is required for anything that depends on dbus_session_daemon | 00:28 |
| Keybuk | modify the definition, and show a job that depends on dbus_session_daemon and gets that address | 00:28 |
| sadmac | dbus_session_daemon(%session): | 00:28 |
| sadmac | when x-session(id:.... | 00:28 |
| Keybuk | no ...s :p | 00:28 |
| sadmac | /* blah blah, skip to last line*/ | 00:29 |
| sadmac | ok | 00:29 |
| sadmac | dbus_session_daemon(%session): | 00:29 |
| sadmac | when x-session(id: %session) | 00:29 |
| sadmac | auto | 00:29 |
| sadmac | eval DBUS_SESSION_BUS_ADDRESS=%session /usr/bin/dbus-session | 00:29 |
| Keybuk | I don't understand your eval line there, could you explain it? | 00:30 |
| sadmac | it substitutes %session for the session argument | 00:30 |
| Keybuk | err, but DBUS_SESSION_BUS_ADDRESS is printed *by* dbus-session | 00:31 |
| Keybuk | that was my point | 00:31 |
| Keybuk | you run dbus-session, grab its stdout, and you get something that looks like an envvar | 00:31 |
| sadmac | ah, I misunderstood the question | 00:31 |
| Keybuk | interestingly, your model is like 0.5 in its treatment of instances | 00:31 |
| Keybuk | in that you have to explicitly define what makes a job unique | 00:31 |
| Keybuk | in your case there, you have to say that it's unique per value of %session | 00:31 |
| Keybuk | I assume that if you try and start one, you have to give a value for %session | 00:31 |
| Keybuk | I'm guessing that: | 00:32 |
| Keybuk | singleton(): | 00:32 |
| sadmac | Keybuk: if you start it manually yes | 00:32 |
| Keybuk | exec foo | 00:32 |
| Keybuk | can only be run once? | 00:32 |
| Keybuk | you can't start multiple copies | 00:32 |
| sadmac | no | 00:32 |
| Keybuk | no you can't, or no you can? | 00:32 |
| sadmac | you can't | 00:33 |
| sadmac | you could do something like: | 00:34 |
| sadmac | singleton(%_nonce_): | 00:34 |
| sadmac | exec foo | 00:34 |
| sadmac | where nonce would be some unique ID that would be filled in for you. | 00:34 |
| Keybuk | ok | 00:34 |
| Keybuk | so let's say you wanted to run a service in a chroot | 00:34 |
| Keybuk | or a group of services | 00:34 |
| Keybuk | you'd have to add %chroot to everything? | 00:35 |
| sadmac | depends. | 00:35 |
| sadmac | if they all run in the same chroot then definitely no | 00:35 |
| Keybuk | why no? | 00:35 |
| Keybuk | I mean have a second copy of everything across two chroots | 00:35 |
| Keybuk | for the record, btw, my equivalent would look like: | 00:36 |
| Keybuk | while x-session | 00:36 |
| Keybuk | eval /usr/bin/dbus-launch --sh-syntax | 00:36 |
| Keybuk | export DBUS_SESSION_BUS_ADDRESS | 00:36 |
| Keybuk | while dbus-session-bus | 00:36 |
| Keybuk | exec /usr/bin/dbus-session-service | 00:36 |
| Keybuk | err | 00:36 |
| Keybuk | while x-session | 00:36 |
| Keybuk | eval /usr/bin/dbus-launch --sh-syntax | 00:36 |
| Keybuk | export DBUS_SESSION_BUS_ADDRESS | 00:36 |
| Keybuk | -- | 00:36 |
| Keybuk | while dbus-session-bus | 00:36 |
| Keybuk | exec /usr/bin/dbus-session-service | 00:36 |
| Keybuk | -- | 00:36 |
| Keybuk | gap between the two jobs got lost there :p | 00:36 |
| sadmac | you have to define 2 states? | 00:37 |
| Keybuk | one for the dbus session bus | 00:37 |
| Keybuk | the other for the service you want to run on it | 00:37 |
| Keybuk | they're services, not states, in my model | 00:37 |
| sadmac | oh | 00:37 |
| sadmac | right | 00:38 |
| sadmac | ok, seeing that I can answer your question | 00:38 |
| sadmac | when x-session(id: %session) | 00:38 |
| sadmac | wait... | 00:38 |
| sadmac | dbus_session_daemon(%session): | 00:39 |
| sadmac | when x-session(id: %session) | 00:39 |
| sadmac | shit. too quick on the copypasta | 00:39 |
| sadmac | dbus_session_daemon(%session, %busaddr): | 00:39 |
| sadmac | when x-session(id: %session) | 00:39 |
| sadmac | auto | 00:39 |
| sadmac | busaddr := exec /usr/bin/dbus-launch --sh-syntax | 00:40 |
| sadmac | dbus_session_service(%busaddr): | 00:41 |
| sadmac | when dbus_session_daemon(%busaddr) | 00:41 |
| sadmac | auto | 00:41 |
| sadmac | exec DBUS_SESSION_BUS_ADDRESS=%busaddr /usr/bin/dbus-session-service | 00:42 |
| Keybuk | I think my way is easier :) | 00:42 |
| sadmac | I don't | 00:43 |
| ion_ | In this case, Keybukâs syntax wins. | 00:44 |
| sadmac | ok | 00:44 |
| sadmac | Keybuk: how do you express the mounting case? | 00:44 |
| Keybuk | there's not enough info in yours to tell | 00:46 |
| Keybuk | could you expand yours a little | 00:46 |
| sadmac | let me flesh them out | 00:47 |
| sadmac | mount(%mountpoint): | 00:47 |
| sadmac | when file-exists(%mountpoint) | 00:47 |
| sadmac | damn! | 00:48 |
| * sadmac needs an irc line editor | 00:48 | |
| Keybuk | I just use vi and paste ;) | 00:49 |
| sadmac | yeah, doing that way now | 00:49 |
| sadmac | mount(%mountpoint, %devname): when file-exists(%mountpoint) exec mount %devname %mountpoint | 00:51 |
| sadmac | mount(auto: true): auto | 00:51 |
| sadmac | wow. fail | 00:51 |
| sadmac | mount(type: nfs): when network() | 00:51 |
| sadmac | mount(type: ntfs, %mountpoint, %devname): exec ntfs3g-mount %mountpoint, %devname | 00:51 |
| sadmac | ok, that, but with linebreaks | 00:51 |
| sadmac | mount(%mountpoint, %devname): when file-exists(%mountpoint) exec mount %devname %mountpoint | 00:52 |
| sadmac | mount(auto: true): auto | 00:52 |
| sadmac | mount(type: nfs): when network() | 00:52 |
| sadmac | mount(type: ntfs, %mountpoint, %devname): exec ntfs3g-mount %mountpoint, %devname | 00:52 |
| * sadmac goes to file a bug against IRSSI | 00:52 | |
| Keybuk | hmm | 00:52 |
| sadmac | I'll pastebin it then | 00:52 |
| Keybuk | surely that's wrong | 00:52 |
| Keybuk | according to your own blog | 00:52 |
| Keybuk | mount(type: nfs): ... | 00:52 |
| Keybuk | simply creates a state where type = nfs | 00:53 |
| Keybuk | it doesn't bind that to any dependant states | 00:53 |
| Keybuk | what you mean is | 00:53 |
| sadmac | Keybuk: no | 00:53 |
| Keybuk | mount(%type): | 00:53 |
| Keybuk | when ... type=nfs ? | 00:53 |
| sadmac | Keybuk: no | 00:53 |
| Keybuk | no? | 00:53 |
| sadmac | mount(type: nfs) means that the below config items apply to all mount states such that type = nfs | 00:54 |
| sadmac | Keybuk: and you never create states in my model | 00:54 |
| sadmac | Keybuk: you just say when they'll be on | 00:54 |
| Keybuk | oh, I see | 00:55 |
| sadmac | Keybuk: the syntax on my blog was designed to facillitate mathiness. It won't always resemble this | 00:55 |
| Keybuk | err | 00:56 |
| Keybuk | so each ...(): is like a while clause? | 00:56 |
| Keybuk | so | 00:56 |
| Keybuk | dbus_session_daemon(%session): | 00:56 |
| Keybuk | ... | 00:56 |
| Keybuk | defines both the dbus session daemon | 00:56 |
| Keybuk | *and* | 00:56 |
| Keybuk | something that depends on the dbus session daemon? | 00:56 |
| Keybuk | to simplify | 00:56 |
| Keybuk | I want food to run | 00:57 |
| Keybuk | (heh) | 00:57 |
| Keybuk | foo(...): | 00:57 |
| Keybuk | exec /usr/sbin/food | 00:57 |
| Keybuk | now I want bard to run along side that | 00:57 |
| Keybuk | I could either do | 00:57 |
| Keybuk | bar(...): | 00:57 |
| Keybuk | when foo | 00:57 |
| Keybuk | exec /usr/sbin/bard | 00:57 |
| Keybuk | or | 00:57 |
| Keybuk | foo(...) | 00:57 |
| Keybuk | exec /usr/sbin/bard | 00:57 |
| sadmac | Keybuk: those are slightly different in one way. notice how I kept the auto keyword? | 00:58 |
| Keybuk | yes, I didn't get that | 00:58 |
| sadmac | Keybuk: in your first writing, it is possible to bring up foo, then bring up bar, but bringing up bar will always bring up foo. | 00:58 |
| Keybuk | right | 00:58 |
| Keybuk | but it means there's two different ways to make one job run with another | 00:59 |
| sadmac | Keybuk: in your second example, both executables shadow the same state, so they are completely non-independant | 00:59 |
| sadmac | Keybuk: the second is a bad idea | 00:59 |
| Keybuk | I'd place a bet now that the second is what most people will write ;) | 00:59 |
| Keybuk | in fact | 00:59 |
| Keybuk | I'd bet you that what most people will write is: | 00:59 |
| Keybuk | runlevel2(...): | 00:59 |
| Keybuk | exec my daemon | 00:59 |
| sadmac | Keybuk: let me translate my dbus one into english | 01:00 |
| sadmac | dbus_session_daemon(%session, %busaddr): // For a state dbus_session_daemon with arguments session and busaddr of any value | 01:01 |
| Keybuk | oh, I think I actually understand how your model works now :) | 01:01 |
| Keybuk | it's quite neat | 01:01 |
| sadmac | ok. | 01:01 |
| sadmac | let me stop there, because I might confuse you again :) | 01:02 |
| sadmac | tell me what you've found | 01:02 |
| Keybuk | you define states | 01:02 |
| Keybuk | and you define things to be done when a given state is true | 01:02 |
| Keybuk | "jobs" are the latter | 01:02 |
| Keybuk | the former are done by things like initctl I guess | 01:02 |
| Keybuk | so your fstab example works because you define states for the items in fstab | 01:02 |
| Keybuk | and the jobs defined items that are processed when those things are true | 01:02 |
| Keybuk | foo(...): | 01:03 |
| Keybuk | exec foo | 01:03 |
| Keybuk | foo(...): | 01:03 |
| Keybuk | when ... | 01:03 |
| Keybuk | exec bar | 01:03 |
| Keybuk | actually adds the when to both? | 01:03 |
| Keybuk | the when introduces the dep to foo, not to the short clip of things-to-be-done-when-foo-is-true, right? | 01:03 |
| sadmac | assuming the (...) is the same for both | 01:03 |
| sadmac | right | 01:03 |
| ion_ | pe025244 * sadmac goes to file a bug against IRSSI | 01:04 |
| sadmac | ion_: yeah, I should go do that | 01:04 |
| ion_ | How about turning paste_join_multiline off? | 01:04 |
| sadmac | ion_: good idea! | 01:04 |
| Keybuk | I think the problem you're going to have is explaining your model in such a way that people don't do | 01:05 |
| Keybuk | runlevel2(): | 01:05 |
| Keybuk | exec my_service | 01:05 |
| Keybuk | because the simplest paragraph | 01:05 |
| Keybuk | "BLAH: exec..." defines a service to be run while the BLAH state is true | 01:05 |
| Keybuk | is going to tell people to do exactly that | 01:06 |
| sadmac | Keybuk: there is some issue there, and some of it can be fixed with more syntax, but fortunately you and I will control most of the initial usage of this :) I think that once my terse and formal self is out of the room and you open up a system defined this way and actually look at the examples it will become clear | 01:07 |
| sadmac | Keybuk: in the long run I don't think its terribly difficult for a sysadmin to do, even if the short term might include a bump or two. It should become natural over time. | 01:08 |
| sadmac | I like about this one that common sense does work quite a bit better for it than for many other models I've played with. | 01:08 |
| Keybuk | I'd be interested to see if you could write an example page of the "writing a service" documentation | 01:09 |
| * Keybuk likes writing end-user documentation as a design method | 01:09 | |
| sadmac | I could do that. | 01:09 |
| sadmac | Keybuk: one of the big goals here was actually to be mathematically rigorous, and for a good reason. We're doing this rewrite because we kept finding out things about the previous mechanism that hadn't occured to us. | 01:11 |
| sadmac | It may be an up hill battle explaining the minutiae of this thing, but no one will /EVER/ tell me something about it that surprises me. Its definition is thorough and complete. | 01:11 |
| sadmac | notting: you missed Keybuk suddenly understanding what I've been yammering about for the past 2 months :) | 01:24 |
| === notting_ is now known as notting | ||
| geiseri_ | hey, how do i change the order of things in the event.d directory, i am on intrepid and my event broke because it needs to wait for hal to start. | 20:21 |
| geiseri_ | on started hal <- is this what i should have there? | 20:29 |
| geiseri_ | if hal is the rc.d step? | 20:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!