[00:21] davecheney: Morning! [00:21] hey [00:22] WOohay! First watcher test just passed [00:23] davecheney: All good there/ [00:23] ? [00:23] watchers! hot damn [00:24] it's good to have you in the trenches with us [00:29] davecheney: Thanks, I actually enjoy it a lot too, and it's getting even more exciting now that we can actually use the stuff we've been doing [00:29] davecheney: Well, or are about to use, anyway [01:20] 3 tests passing! [01:21] niemeyer: i have UseSSH patched into mstate [01:22] davecheney: Wot [01:22] woot [01:22] i'm going to see if I can change the test suites to run twice, once direct, the other via ssh [01:22] the state/* tests don't do this [01:22] they have a simple test for ssh forwarding only [01:23] actually, i'll do that in a followup CL [01:26] AAAAAAAAAAAAAAAAAAAAGH [01:26] i forgot the prereq !!! [01:54] Uh oh :) [03:05] and it takes shape.. [06:03] Watcher foundation is up for review.. [06:03] and I'm down for bed.. [06:03] niemeyer, gn [06:04] fwereade: Heya [06:04] fwereade: Up early? Or maybe I'm late..? :) [06:04] niemeyer, I'm a bit early, you're very late :) [06:04] niemeyer, sounds like a fruitfulday though [06:05] fwereade: Indeed.. pretty happy with it [06:05] niemeyer, cool [06:05] fwereade: Slightly dense, but not too much code at all [06:05] niemeyer, great [06:06] fwereade: and performant.. a thousand events written down, monitored and dispatched in a couple of seconds [06:06] niemeyer, fantastic :D [06:07] fwereade: Unblocking FTW :) [06:07] * niemeyer heads to a nice shower and bed.. [06:07] fwereade: Have a good time there [06:07] niemeyer, sleep well :) [06:09] fwereade: tks! [06:13] niemeyer: great stuff! [07:09] fwereade: mornin' [07:09] rogpeppe, heyhey [07:09] * rogpeppe goes to look at the watcher foundation... [07:31] rogpeppe, trivial: https://codereview.appspot.com/6488092 [07:32] fwereade: all code deletion LGTM! [07:32] rogpeppe, cheers :) [07:53] rogpeppe, another trivial: https://codereview.appspot.com/6503087 [07:57] fwereade: isn't that just the kind of thing that log.Debugf is for? we already *have* a Debug flag [07:58] rogpeppe, one global debug flag is IMO not adequate -- *most* of the time we don't need this logging, but it has on occasion been invaluable [07:58] rogpeppe, when it's running, though, it overwhelms theagent logs with spam [07:58] fwereade: maybe we should remove the global debug flag entirely [07:59] rogpeppe, possibly -- but I suspect that fully "correct" logging is likely to be a contentious subject and would prefer to avoid that rabbit hole while I can ;p [07:59] fwereade: or provide some way of registering particular debug flags [07:59] rogpeppe, yeah, indeed, *I* think we need something like that but niemeyer was -1 in related discussions a while ago [07:59] fwereade: fair enough. LGTM with the above reservations. [07:59] rogpeppe, cheers :) [08:45] rogpeppe, I'm heading out to work in a cafe for a while, bbs [10:30] davecheney: hiya [10:30] going home again, later all [10:31] rog: hey [10:34] hey all. [10:34] I'm not really here today, but hello. [10:35] hello not-here Aram [10:51] davecheney, Aram: trivial LGTM please? https://codereview.appspot.com/6495103/ [10:55] rog: fire at will [10:55] davecheney: ta [11:03] fwereade: as a stopgap measure, how about: http://paste.ubuntu.com/1190585/ [11:04] rog, something like that is indeed a possibility, that was kinda where we started [11:09] fwereade: gets us through for the time being anyway, i think. and doesn't pretend to encapsulate an agent, just provides a way for a given agent to find its name. [11:34] fwereade: FYI i think your trivial.EnsureDir is exactly equivalent to os.MkdirAll [11:35] rog, ha, that'll learn me :/ [11:35] fwereade: apart from it produces a slightly different error message when the target isn't a directory :-) [12:09] fwereade: how about /var/lib/juju/agents/unit-foo-3 as a uniter directory name (rather than /var/lib/juju/units/foo-3) ? then all the agent directories can live under the same directory. [12:09] rog, definitely yes [12:09] fwereade: great. done :-) [12:10] rog, even though none of the other agents need local storage yet, it seems cray not to think about them [12:10] fwereade: +1 [12:10] rog, ah ok -- what are you working on atm? [12:10] fwereade: i'm fixing that container bug [12:10] fwereade: where it's using the wrong path [12:11] fwereade: because it's directly affecting me currently [12:11] fwereade: erm, are you on the same thing? [12:11] rog, not exactly... I don;t think... but which bug? [12:11] fwereade: a bug i mentioned yesterday (but haven't actually reported) [12:12] fwereade: where container is looking up the path in $PATH [12:12] fwereade: but it needs to use the agent name in the executable path [12:12] fwereade: otherwise upgrades won't work [12:13] rog, ah right, if that were still around I'd be drive-by fixing it next time I saw it [12:13] rog, but knock yourself out :) [12:13] fwereade: thus far, until i tried earlier today, we haven't tried upgrading a non-cloudinit-started agent yet [12:13] fwereade: i'm already reeling from the blow [12:14] rog, when does that happen except on unit dpeloyemnt? [12:14] rog, because container.Deploy is just generally broken [12:14] fwereade: it doesn't [12:15] fwereade: oh, how else is it broken? [12:15] rog, no state info [12:15] fwereade: i'll fix it in this CL [12:15] rog, no logfiles, no output, the upstart stuff is just generally inconsistent with the way agents are started in cloudinit [12:15] fwereade: ah, i now understand your remark yesterday [12:16] fwereade: "can we get StateInfo from State?" [12:16] rog, ha, yeah :) [12:16] rog, actually just passing it around is not really any trouble [12:16] fwereade: well, we can't even get a State from a Unit AFAIK [12:16] rog, indeed [12:17] Deploy(environs.Environ, *state.Unit) ? [12:18] rog, hmm, maybe, why get an environ when everything that deploys should have a stateinfo readily available? [12:19] fwereade: sounds reasonable to me. i'll see how it pans out. [12:19] rog, cool [12:19] brb [12:19] fwereade: it's a kind of moral equivalent of Environ.StartInstance if you think about it like that [12:30] rog, gut still says -1 but I'll wait and see :) [12:30] fwereade: -1 to what? [12:31] rog, giving an Environ to Deploy... but I could well be wrong [12:31] fwereade: (i wasn't suggesting passing an environs in - Environ.StartInstance takes a StateInfo as an argument) [12:31] s/environs/environ/ [12:31] rog, ah! [12:31] rog, ok, sorry :) [13:40] fwereade: environs.VarDir is going :-) [13:40] rog, excellent news [13:46] fwereade: just looking at worker/uniter/tools_test.go. this seems a little weird: [13:46] s.toolsDir = c.MkDir() [13:46] toolsDir := filepath.Join(s.varDir, "tools") [13:46] err := os.Mkdir(toolsDir, 0755) [13:46] is that first s.toolsDir assignment a mistake? [13:46] * fwereade looks [13:47] rog, I think it's sane, but I agree the names are a bit off [13:48] fwereade: so what are the two meanings of "toolsDir" there? [13:48] niemeyer: yo! [13:49] niemeyer: good work on the watcher foundation BTW [13:49] Hello! [13:49] rog: Hah [13:49] rog: From the amount I've heard about this, I thought you'd be significantly happier ;-) [13:49] niemeyer: not quite sure i get you there [13:50] rog: "I will be really happy when I see watchers working." -- Roger Peppe [13:50] niemeyer: haven't seen 'em working yet! [13:51] rog, s.toolsDir is the place the tools are actually stored; toolsDir is what environs thinks the main tools dir is [13:51] niemeyer: but it looks good. [13:51] rog: Run the tests and enjoy then [13:51] :) [13:51] rog, it is probably not necessary, but when I was writing it all I knew was that thet tools would actually be a sy,mlink away, so it seemed sensible to test it that way [13:51] rog, your changes sound likely to make that redundant [13:54] fwereade: ah i see. so s.toolsDir could be environs.ToolsDir(someVersion) [13:54] rog, yeah, exactly [13:59] fwereade: this is what i'm doing: http://paste.ubuntu.com/1190853/ [14:00] rog, that looks ideal [14:01] fwereade: great [14:21] Alright! [14:21] rog: Carefully responded your concerns with background, and repushed with the fixes [14:21] rog: Thanks for the review [14:21] I'm now stepping out for some holidaying [14:21] niemeyer: have a great time! you deserve it. [14:22] rog: Thanks! [15:07] rog, this is pleasing, I find myself bumping up against wanting a ToolsDir just as you suggested yesterday [15:08] fwereade: yesterday? or just now? [15:08] rog, I thought yesterday -- did you show me something other than ToolsSuite today? [15:09] rog, I presume it's pretty much what you've been doing, what with the VarDir removal [15:09] fwereade: ah, did i have a type named ToolsDir? [15:09] rog, heh, maybe that wasn't its name [15:09] fwereade: tools.Dir perhaps [15:10] rog, that could be it :) [15:10] fwereade: i think i'm happier passing around varDir tbh [15:10] fwereade: i'm not sure the type is that useful [15:10] rog, that also works for me tbh [15:10] fwereade: i quite like the way it's turning out, and it's not too disruptive. [15:12] rog, excellent... I think I have something nice but it *is* a bit disruptive, I need to keep poking before I can decide whether it's right [15:21] rog, I have a sudden feeling that it would be neat to use "agents/unit-x-1/tools" rather than "tools/unit-x-1" [15:22] rog, I suppose it requires that we create the agent directory for everything, wich is slightly inconvenient [15:22] fwereade: i don't think so. [15:22] fwereade: it also means we can't have all the tools directories sitting in the same parent [15:22] rog, but having the stuff that the agent depends on within the agent's own directory feels like a nice thing [15:22] fwereade: with simple same-directory symlinks between them [15:22] fwereade: several agents may depend on the same tools [15:22] rog, what's wrong with absolute symlinks? [15:22] rog, I know that [15:23] fwereade: i *think* it's neater to have all the tools directories in one place [15:24] fwereade: and as you say, currently we don't need to create a directory for most agents [15:24] rog, it feels even neater to me to only have the real tools directories there [15:24] fwereade: so agents/unit-x-1/tools would be a symlink? [15:25] fwereade: i prefer relative symlinks too [15:25] fwereade: as it is (well, could be :-]), we can move the juju directory somewhere else, start things with a different --juju-dir and it'll work [15:26] rog, fair enough [15:26] * rog reserves the right to change his mind, as always :-) [16:06] Hey all. Good work this week. Review with sabdfl & managers went well today. [16:09] mramm: thanks [16:09] mramm: things are coming along nicely i think. as always the horizon recedes as we get towards it though :-) === bcsaller1 is now known as bcsaller [16:14] mramm, cool [16:32] dammit, I think I have something really good coming along, but I have to go [16:32] fwereade: bother, i'm about to propose the vardir change and thought you might like a look :-) [16:32] fwereade: but fair enough, it's friday night! [16:32] fwereade: have a great weekend! [16:33] rog, that is extremely relevant to my interests, I will almost certainly look at it over the w/e [16:33] rog, and you :) [16:33] fwereade: cool [16:33] fwereade: all tests just ran clean, yay [16:33] * fwereade cheers [16:36] fwereade: this branch is just a prelude to the branch that fixes container though, i'm afraid [16:36] fwereade: https://codereview.appspot.com/6501106 [16:36] rog, cheers, I'll open the tab but I really must go [16:36] rog, take care, have fun :) [16:45] * rog thinks that 3 hours for that amount of refactoring is pretty good going. huzzah for static typing! [16:46] fwereade: oh yes, incidentally this also naturally fixes the bug that --juju-dir didn't work :-) [17:09] right, that's me for the weekend. [17:09] see y'all monday; have a good one!