[07:44] <rog> TheMue, fwereade: mornin'
[07:45] <fwereade> rog, TheMue, heyhey
[08:01] <TheMue> moin rog and fwereade
[08:02] <TheMue> fwereade: After my watcher moving proposal this morning I'm now testing the test refactoring we talked about. Looks fine.
[08:17] <fwereade> TheMue, cool
[08:19] <TheMue> fwereade: So, done for the "real" watchers. Now for the watcher package and it's done.
[09:47] <dpkingma> Hello everyone!! I'm looking for a Juju Charm for MongoDB v2.0+
[10:30] <rog> fwereade: review delivered on the RPC CL
[10:41] <dpkingma> NM. has been answered!
[10:58] <rog> fwereade: review delivered on client RPC CL
[10:58] <fwereade> rog, tyvm
[10:59] <rog> fwereade: have you looked at the comments on the server CL?
[10:59] <fwereade> rog, just starting too, need to digest them a little
[10:59] <rog> fwereade: cool
[11:00] <rog> fwereade: i think that losing the SuperCommand will be a useful simplification
[11:02] <fwereade> rog, indeed, that's the bit I need to digest, because it doesn't fit my personal conception of the problem at all -- my current thinking is that SC already does exactly and precisely the job we need -- but you may well have a point :)
[11:03] <rog> fwereade: consider that we will never get flags *before* the command name. and we already know what command to execute. so we aren't using any of SC's functionality.
[11:12] <fwereade> rog, SC doesn't have that functionality
[11:12] <fwereade> rog, the recent split is all about separating the log stuff from the command selection stuff
[11:12] <fwereade> rog, (er, ok, it does, we moved the Log back in -- but the intent was absolutely that it be optional)
[11:13] <rog> fwereade: AFAICS SC is all about intermingling the flags from before the command and after the command, and selecting the command.
[11:13] <rog> fwereade: but we don't care about either of those things here
[11:14] <fwereade> rog, well, we do care about selecting the command, and the convenient representation of the data is in fact the representation that happens to be perfectly convenient already
[11:14] <fwereade> rog, you're just proposing a different way of selecting a command
[11:15] <rog> fwereade: that's true. one that's considerably simpler :-)
[11:15] <fwereade> rog, my vague idea was that a context should be able to just produce a list of commands it implements, and that the selection business could be taken care of by something that already does that
[11:15] <rog> IMO
[11:16] <rog> fwereade: but if a context can simply return a command for a given name, isn't that just as easy to do?
[11:16] <rog> fwereade: i don't see why we take the trouble to register all those commands with SC when we *already know* what command we're going to run!
[11:21] <dpkingma> Hi everyone! Question: is there any info on how to deploy stuff with juju on my own OpenStack cloud? Can't find any info online...
[11:22] <fwereade> dpkingma, very briefly: use the ec2 provider and set the ec2-uri, s3-uri, default-image-id and default-instance-type fields in its config
[11:22] <rog> pwd
[11:24] <dpkingma> fwereade: thanks I'll try that!
[11:29] <fwereade> rog, it seems to me that we know the name of the command we need to run but that actually executing it involves some extra work; and that it is surely convenient for a server.Context to know what commands it implements; but that it does not necessarily follow that we need to duplicate the command selection mechanism
[11:30] <rog> fwereade: the "command selection mechanism" is one map lookup. i don't see that it's any significant complexity.
[11:31] <rog> fwereade: but when i saw the SuperCommand logic, i had to think quite hard about what was actually going on. hence my suggestion.
[11:31] <fwereade> rog, and building the map in the first place; but I don't see how SC represents significant complexity either
[11:32] <rog> fwereade: it's a lot more complex than a simple map lookup
[11:32] <fwereade> rog, sorry -- it seemed perfectly natural to reuse the code that happened to solve precisely the problem we have here
[11:32] <rog> fwereade: i don't think it's solving the problem we've got here. i think you're modifying the problem so it looks like something that is good for SC :-)
[11:33] <rog> fwereade: try the code without using SC there. i *think* it will look a reasonable amount nicer.
[11:33] <fwereade> rog, it's building the map and extracting the command name and using it to select a command... and I agree that it's not complex, but it is work that's already been done
[11:33] <rog> fwereade: and if not, then let's use SC
[11:34] <fwereade> rog, SC takes a list which is a subcommand name followed by its args and does the needful
[11:34] <rog> fwereade: building the map is the same complexity as building the slice, which it has to do currently. the command name already has to be extracted by the juju client.
[11:34] <rog> fwereade: actually SC takes a list which is flags followed by subcommand name followed by flags followed by args...
[11:35] <fwereade> rog, (please do not assume my motivations -- I'm not *trying* to use SC, I merely observed that it precisely followed the problem)
[11:35] <fwereade> rog, only if you set the Log field
[11:37] <rog> fwereade: sorry, i wasn't trying to assume your motivations. i'm going from my initial gut reaction when i saw the code, which hasn't gone away on closer inspection. i think this would be simpler without SC here.
[11:38] <rog> fwereade: and easier to understand.
[11:39] <fwereade> rog, I think we need to figure out exactly what are differences are wrt the definition of simplicity :)
[11:40] <rog> fwereade: actually SuperCommand always takes flags followed by subcommand name - it always accepts --help for example.
[11:40] <rog> fwereade: lines of code is a good start
[11:40] <fwereade> rog, I see it and I think "right, a small chunk of the problem uses a well-understood type to so work that that type is expressly designed to do, I can forget that aspect of the problem for now"
[11:41] <fwereade> rog, s/to so work/to do work/
[11:41] <rog> fwereade: i see it and think "that entire cmd function does nothing useful"
[11:41] <fwereade> rog, well, it uses the pieces we have in play right now to do its job
[11:42] <rog> fwereade: we already have the pieces IMHO - the built in map type and possibly the existing *Log type are all that's needed.
[11:42] <fwereade> rog, we definitely don't want a Log there
[11:42] <rog> fwereade: that's fine, we don't need to use it
[11:42] <rog> fwereade: even better!
[11:43] <rog> fwereade: so instead of building a slice of Commands and leaving it up to something else to do the selection, we can use a map of commands and an index expression...
[11:44] <rog> fwereade: which also means that potentially we could return a more useful error message when someone tries to execute a command in the wrong context
[11:45] <fwereade> rog, isn't "here's a nicely-formatted list of the appropriate commands for this context" useful error-message-wise?
[11:45] <rog> fwereade: not as useful as "you can't execute this command in this context for this reason"
[11:45] <rog> fwereade: supercommand will just say "command not found" or whatever
[11:46] <rog> hmm
[11:46] <fwereade> rog, and list the ones it can, which is IMO useful
[11:51] <rog> fwereade: i'm not sure. to the user, they all look like separate commands. seeing "usage: (->jujuc) ..." and a list of other commands isn't great.
[11:51] <rog> fwereade: in particular the (->jujuc) thing
[11:52] <fwereade> rog, heh, I felt that was useful information
[11:52] <rog> fwereade: it's feels more like an implementation detail to me
[11:52] <rog> s/it's/it/
[11:53] <fwereade> rog, conceptually perhaps, but not one we can really hide from someone who takes the trouble to look
[11:53] <rog> fwereade: sure. but we don't want to flaunt it to everyone that happens to mistype a command name...
[11:54] <fwereade> rog, that'll just give them command not found
[11:54] <fwereade> rog, it's only if they're hitting something symlinked to jujuc in the first place
[11:55] <rog> fwereade: ok, to anyone that uses a command in the wrong context then ....
[11:55] <fwereade> rog, this is moot anyway, AIUI the long-term plan is that they should all always be available anyway
[11:55] <fwereade> rog, (but the wrong-context thing is IMO exactly when it'll be useful to see the commands that are valid in the current context)
[11:56] <rog> fwereade: there's nothing stopping us showing them anyway.
[11:57] <rog> fwereade: if we decide that's what we want. but an error message better than "unrecognised command" would be good.
[11:57] <fwereade> rog, that feels like still more reimplementation of existing functionality...
[11:58] <rog> fwereade: sure. i don't think it's really necessary. getting the right error message is more important. we *did* recognise the command, we just didn't act on it.
[11:59] <fwereade> rog, well, probably, anyway... no doubt someone will try to call jujuc directly sometime ;)
[12:00] <rog> fwereade: that's fine - we will get "unrecognised command" in that case :-)
[12:01] <fwereade> rog, ok, I'll give it a go
[12:01] <rog> fwereade: thanks for bearing with me :-)
[12:02] <fwereade> rog, please understand that it's frustrating to work on something for a week with the clear intent that it will be used imminently, and to then have it dropped on the floor
[12:03] <fwereade> rog, this essentially means that all the discussion and argument about how to extract Log from SuperCommand was pure academic wankery :(
[12:04] <rog> fwereade: yes, i do understand that very well, and please believe me when i say that i wouldn't suggest it unless i thought it would be a significant improvement
[12:04] <rog> fwereade: oh i see.
[12:05] <fwereade> rog, this turn of events is maybe also evidence that we flat-out suck at predicting the future ;)
[12:05] <fwereade> rog, don't get me wrong, SC turned out really nice, but...
[12:05] <rog> fwereade: well, that is always true in s/w development at least. anything else, i can predict 3 days in advance perfectly.
[12:06] <fwereade> rog, sure; but your simplicity argument does again hinge on future usage
[12:06] <rog> fwereade: i'm really happy with the way SC turned out too. it means we can add extra flags easily too if we want, in a nicely organised way
[12:06] <fwereade> rog, suggestion:
[12:07] <fwereade> rog, I follow your advice but for different reasons
[12:07] <rog> fwereade: i'm not sure. my simplicity argument is based on looking at the code as is
[12:07] <rog> fwereade: and seeing that it could be made simpler
[12:08] <fwereade> rog, that by implementing it as GetCmd(contextId, name) (string, error) I can thereby punt on the question of selection mechanism until we have an actual supplier of commands implemented
[12:08] <rog> fwereade: that's true too
[12:08] <fwereade> rog, you get simpler code to review and we defer any argument about the right way to do something until we're actualy doing it ;p
[12:09] <rog> fwereade: i wasn't sure whether you'd already got some code that implemented GetCmds already lurking somewhere though
[12:09] <fwereade> rog, no -- it's the simplest thing I could predict it would be easy to get from a Context :)
[12:10] <rog> fwereade: well, i'm glad about that at least - no downstream branches to mangle
[12:22] <rog> TheMue: ping
[12:22] <TheMue> rog: pong
[12:22] <rog> TheMue: i got a test failure on TestUnitWatchPorts
[12:22] <rog> TheMue: i've worked out the issue, and i think i have a slightly better way of working that test
[12:23] <rog> TheMue: how about this? http://paste.ubuntu.com/949642/
[12:23] <rog> TheMue: this issue was a timeout BTW
[12:23] <rog> TheMue: the receiver of the changes wasn't waiting long enough for the generator
[12:24] <TheMue> rog: The tests are currently refactored to a more serialized way. But that will come in after the moving has a LGTM by Gustavo.
[12:24] <rog> TheMue: this change makes them both run in lock step (so it should be faster) and also uses the same table for both
[12:24] <rog> TheMue: ok, so you've got a similar change in the offing?
[12:24] <TheMue> rog: Yep
[12:25] <TheMue> rog: Wait, I paste one example.
[12:25] <rog> TheMue: cool. i'll ignore the test failures for the moment then.
[12:27] <TheMue> rog: http://paste.ubuntu.com/949648/
[12:29] <rog> TheMue: that's cool. no need for the extra goroutine, of course, which i hadn't realised. nice.
[12:29] <TheMue> rog: I followed an idea of William.
[12:29] <rog> TheMue: 't'was a good idea
[12:29] <TheMue> rog: Indeed.
[12:38] <TheMue> fwereade: ping
[12:38] <fwereade> TheMue, pong
[12:39] <TheMue> fwereade: Just seen that you've got no roomie, like me. Shall I notify Marianna?
[12:39] <fwereade> TheMue, sure :)
[12:39] <TheMue> fwereade: OK, will do.
[12:39] <fwereade> TheMue, I'm reasonablycivilised most of the time ;)
[12:40] <TheMue> fwereade: I'll try my best to do so too. *lol*
[12:40] <rog> TheMue: where do you find out your roomie?
[12:44] <TheMue> rog: I went to the wiki and there "latest changes".
[12:45] <TheMue> rog: There's a "PeopleDetail" page.
[12:45] <rog> TheMue: got it
[12:47] <TheMue> fwereade: Mail is sent.
[12:47] <fwereade> rog, new cut at https://codereview.appspot.com/6120054/
[12:47] <fwereade> rog, actually hold off, I can simplify further
[12:48] <rog> fwereade: yeah, jujucDoc and jujucPurpose can go, at least
[12:48] <fwereade> rog, that was precisely what I realised :)
[12:52] <rog> fwereade: LGTM
[12:52] <fwereade> rog, cool, thanks
[12:53] <rog> fwereade: i hope it feels ok
[12:53] <fwereade> rog, ii's good, thank you :)
[12:57] <fwereade> rog, btw, I've really come to appreciate lbox propose publishing all my drafts, really nice idea
[12:57] <rog> fwereade: i like that too. and the fact that i have to have a clean branch when proposing
[12:58] <fwereade> rog, yeah, that's saved me a lot of embarrassment :)
[12:58] <rog> fwereade: i wish cobzr switch would do that check too actually
[12:59] <fwereade> rog, I've actually given upon cobzr, it surprises me slightly more than bzr does and that makes me paranoid
[12:59] <rog> fwereade: i find it works pretty well actually.
[13:00] <rog> fwereade: it would be nice if there was a universal way of specifying a co-located branch, so i could diff against them
[13:00] <fwereade> rog, it's pretty clearly to do with a part of my brain that hasn't quite adapted to DVCSs in general
[13:00] <rog> fwereade: so how do you set your GOPATH?
[13:00] <fwereade> rog, so that's clearly soluble
[13:01] <fwereade> rog, but the easy diffing is too much to give up
[13:01] <fwereade> rog, sad to say, I'd rather just move directories ;)
[13:01] <rog> fwereade: i usually just push to launchpad and diff against there. slow but quick enough for my purposes
[13:02] <fwereade> rog, that would be fine if *something* I did didn't cause cobzr checkouts to occasionally forget their push branch :)
[13:03] <rog> fwereade: ah, i have seen that before, i think. but nothing that caused too many problems.
[13:27] <andrewsmedina> rog: thanks for the reviews :)
[13:27] <rog> andrewsmedina: np
[13:45] <niemeyer> Mornings!
[13:46] <fwereade> heya niemeyer
[13:47] <niemeyer> fwereade: Hey
[13:59] <niemeyer> fwereade: I suspect the diff in https://codereview.appspot.com/6116049/ got mixed up with review points that we've sorted elsewhere
[14:02] <niemeyer> fwereade: If that's the case, we can just get it in and let the other issues be sorted in whatever CL they are being debated
[14:38] <andrewsmedina> Guest17887: I will improve testing for LXC using the same line you used forthe ssh
[14:39] <rogpeppe>  andrewsmedina: that sounds reasonable.
[14:45]  * niemeyer missing fwereade at the moment
[14:45] <niemeyer> I don't understand why the checks in https://codereview.appspot.com/5845051/diff/17001/charm/charm_test.go are being removed..
[14:48] <niemeyer> Ahh, I think I see.. it was moved to another test
[14:50] <niemeyer> Nice
[15:12] <TheMue> So, have to leave.
[15:13] <TheMue> niemeyer: Watcher moving is in at https://codereview.appspot.com/6131045/, could you please review? Thx.
[15:14] <TheMue> niemeyer: Watcher test refactoring is also ready locally (but based on the moved watchers). So it could be reviewed immediatelly after submit of moved watchers.
[15:18] <niemeyer> TheMue: Will do
[15:18] <niemeyer> TheMue: Cheers
[15:18]  * niemeyer => lunch too
[15:53] <rogpeppe> niemeyer: i'm seeing a store test failure: http://paste.ubuntu.com/950070/
[15:57] <rogpeppe> niemeyer, fwereade: https://codereview.appspot.com/6128046/
[16:01] <rogpeppe> fwereade: https://codereview.appspot.com/6128046/
[16:01] <rogpeppe> fwereade_: https://codereview.appspot.com/6128046/
[16:02] <fwereade_> rogpeppe, cheers
[16:04] <rogpeppe> fwereade_: *slightly* concerned about the fact that my test will only work if the juju build succeeds, but we're never gonna break the build, right?
[16:04] <fwereade_> rogpeppe, that sort of thing never happens at all ;p
[16:04] <fwereade_> rogpeppe, but tbh it's not clear what you can do about it...
[16:04] <rogpeppe> fwereade_: yeah. i don't think it matters too much.
[16:05] <rogpeppe> fwereade_: fix the build, then the tests can start working again
[16:15] <niemeyer> rogpeppe: Hmm.. is it failing consistently or some times?
[16:16] <rogpeppe> niemeyer: just that once, but i haven't run all the tests since then. will try again.
[16:16] <niemeyer> rogpeppe: I will increase the timeout there
[16:18] <rogpeppe> niemeyer, fwereade_: i'm off slightly early today. very shortly in fact.
[16:19] <fwereade_> rogpeppe, niemeyer: off in a few short minutes myself
[16:19]  * fwereade_ almost avoids saying something about friday, friday...
[16:19] <niemeyer> rogpeppe, fwereade_: Cool, I'll see you guys on Monday, hopefully
[16:19] <niemeyer> I'll be working from us-east, so we'll have little-to-no overlap
[16:21] <rogpeppe> niemeyer: did you see my latest CL BTW? archiving of juju client now works. only the S3 and shell script stuff to do.
[16:21] <niemeyer> rogpeppe: Woohay!
[16:22] <rogpeppe> niemeyer: store tests passed that time BTW
[16:22] <niemeyer> rogpeppe: init is close
[16:22] <rogpeppe> niemeyer: ?
[16:22] <niemeyer> rogpeppe: Cool.. it's the timeout indeed
[16:22] <niemeyer> rogpeppe: zkinit on server side
[16:22] <rogpeppe> niemeyer: cool. i reckon that'll probably be done by the time i've finished the S3 upload code
[16:23] <rogpeppe> niemeyer: a good place to stop for the day i reckon. have a good weekend all. and niemeyer, have a good flight, hope your ears give you no trouble...
[16:24] <rogpeppe> fwereade_: cheerio
[16:24] <niemeyer> rogpeppe: zkinit itself is done or mostly done I think.. next after the upload stuff is tweaking user-data setup to pick the right commands and run them
[16:24] <niemeyer> rogpeppe: I'm so excited about this stuff, btw
[16:24] <fwereade_> rogpeppe, happy weekend
[16:24] <rogpeppe> niemeyer: 'xactly. "the shell script stuff"
[16:24] <niemeyer> rogpeppe: Yeha
[16:24] <rogpeppe> niemeyer: me too.
[16:25] <niemeyer> rogpeppe: That mechanism will make development of the upcoming stuff such a breeze.. I can barely believe we'll be able to just say upgrade-juju --upload-tools and *test the new code*
[16:26] <rogpeppe> niemeyer: the go tool made it almost trivial... kudos to russ
[16:26] <niemeyer> rogpeppe: Hmm.. I don't think that's entirely related
[16:26] <niemeyer> rogpeppe: Kudos to all of them for having standalone binaries.. *that's* the huge facilitator
[16:28] <fwereade_> gn all, take care
[16:28] <rogpeppe> niemeyer: yeah, but that i could do "GOBIN=$tmp go install launchpad.net/juju/go/cmd/..." and have all the binaries made for me and up to date is just lovely
[16:29] <niemeyer> rogpeppe: Ah, I didn't realize you were going in that direction
[16:29] <niemeyer> fwereade_: Night man
[16:29] <rogpeppe> niemeyer: hope it works ok for you.
[16:29] <niemeyer> rogpeppe: Thinking..
[16:30] <niemeyer> rogpeppe: This is most awesome for dev, but it means you need the dev environment in place too..
[16:30] <niemeyer> rogpeppe: The alternative I was thinking off was looking for the tools in $PATH
[16:30] <niemeyer> s/off/of
[16:31] <niemeyer> rogpeppe: This would work in all cases, as long as one has the tools in their path.. both in dev and in cases when juju is installed via debs
[16:31] <rogpeppe> niemeyer: i'd assumed non-devs would use public binaries
[16:32] <niemeyer> rogpeppe: Sure, that's an assumption we can make, but the question is why
[16:32] <niemeyer> rogpeppe: What are we trading off
[16:34] <rogpeppe> niemeyer: i can easily add logic to find binaries in $PATH to the current code.
[16:34] <rogpeppe> niemeyer: perhaps in the next CL?
[16:35] <niemeyer> rogpeppe: Yeah, we can even wait longer
[16:35] <niemeyer> rogpeppe: Until we have answers for that
[16:35] <niemeyer> rogpeppe: Your scheme sounds better for the situation we're currently in
[19:42]  * niemeyer goes for a few errands in preparation for the trip