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