=== flaviamissi_ is now known as flaviamissi [07:44] TheMue, fwereade: mornin' [07:45] rog, TheMue, heyhey [08:01] moin rog and fwereade [08:02] fwereade: After my watcher moving proposal this morning I'm now testing the test refactoring we talked about. Looks fine. [08:17] TheMue, cool [08:19] fwereade: So, done for the "real" watchers. Now for the watcher package and it's done. [09:47] Hello everyone!! I'm looking for a Juju Charm for MongoDB v2.0+ [10:30] fwereade: review delivered on the RPC CL [10:41] NM. has been answered! [10:58] fwereade: review delivered on client RPC CL [10:58] rog, tyvm [10:59] fwereade: have you looked at the comments on the server CL? [10:59] rog, just starting too, need to digest them a little [10:59] fwereade: cool [11:00] fwereade: i think that losing the SuperCommand will be a useful simplification [11:02] 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] 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] rog, SC doesn't have that functionality [11:12] rog, the recent split is all about separating the log stuff from the command selection stuff [11:12] rog, (er, ok, it does, we moved the Log back in -- but the intent was absolutely that it be optional) [11:13] fwereade: AFAICS SC is all about intermingling the flags from before the command and after the command, and selecting the command. [11:13] fwereade: but we don't care about either of those things here [11:14] 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] rog, you're just proposing a different way of selecting a command [11:15] fwereade: that's true. one that's considerably simpler :-) [11:15] 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] IMO [11:16] fwereade: but if a context can simply return a command for a given name, isn't that just as easy to do? [11:16] 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] 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] 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] pwd [11:24] fwereade: thanks I'll try that! [11:29] 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] fwereade: the "command selection mechanism" is one map lookup. i don't see that it's any significant complexity. [11:31] 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] rog, and building the map in the first place; but I don't see how SC represents significant complexity either [11:32] fwereade: it's a lot more complex than a simple map lookup [11:32] rog, sorry -- it seemed perfectly natural to reuse the code that happened to solve precisely the problem we have here [11:32] 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] fwereade: try the code without using SC there. i *think* it will look a reasonable amount nicer. [11:33] 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] fwereade: and if not, then let's use SC [11:34] rog, SC takes a list which is a subcommand name followed by its args and does the needful [11:34] 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] fwereade: actually SC takes a list which is flags followed by subcommand name followed by flags followed by args... [11:35] 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] rog, only if you set the Log field [11:37] 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] fwereade: and easier to understand. [11:39] rog, I think we need to figure out exactly what are differences are wrt the definition of simplicity :) [11:40] fwereade: actually SuperCommand always takes flags followed by subcommand name - it always accepts --help for example. [11:40] fwereade: lines of code is a good start [11:40] 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] rog, s/to so work/to do work/ [11:41] fwereade: i see it and think "that entire cmd function does nothing useful" [11:41] rog, well, it uses the pieces we have in play right now to do its job [11:42] 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] rog, we definitely don't want a Log there [11:42] fwereade: that's fine, we don't need to use it [11:42] fwereade: even better! [11:43] 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] 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] rog, isn't "here's a nicely-formatted list of the appropriate commands for this context" useful error-message-wise? [11:45] fwereade: not as useful as "you can't execute this command in this context for this reason" [11:45] fwereade: supercommand will just say "command not found" or whatever [11:46] hmm [11:46] rog, and list the ones it can, which is IMO useful [11:51] 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] fwereade: in particular the (->jujuc) thing [11:52] rog, heh, I felt that was useful information [11:52] fwereade: it's feels more like an implementation detail to me [11:52] s/it's/it/ [11:53] rog, conceptually perhaps, but not one we can really hide from someone who takes the trouble to look [11:53] fwereade: sure. but we don't want to flaunt it to everyone that happens to mistype a command name... [11:54] rog, that'll just give them command not found [11:54] rog, it's only if they're hitting something symlinked to jujuc in the first place [11:55] fwereade: ok, to anyone that uses a command in the wrong context then .... [11:55] rog, this is moot anyway, AIUI the long-term plan is that they should all always be available anyway [11:55] 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] fwereade: there's nothing stopping us showing them anyway. [11:57] fwereade: if we decide that's what we want. but an error message better than "unrecognised command" would be good. [11:57] rog, that feels like still more reimplementation of existing functionality... [11:58] 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] rog, well, probably, anyway... no doubt someone will try to call jujuc directly sometime ;) [12:00] fwereade: that's fine - we will get "unrecognised command" in that case :-) [12:01] rog, ok, I'll give it a go [12:01] fwereade: thanks for bearing with me :-) [12:02] 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] rog, this essentially means that all the discussion and argument about how to extract Log from SuperCommand was pure academic wankery :( [12:04] 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] fwereade: oh i see. [12:05] rog, this turn of events is maybe also evidence that we flat-out suck at predicting the future ;) [12:05] rog, don't get me wrong, SC turned out really nice, but... [12:05] fwereade: well, that is always true in s/w development at least. anything else, i can predict 3 days in advance perfectly. [12:06] rog, sure; but your simplicity argument does again hinge on future usage [12:06] 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] rog, suggestion: [12:07] rog, I follow your advice but for different reasons [12:07] fwereade: i'm not sure. my simplicity argument is based on looking at the code as is [12:07] fwereade: and seeing that it could be made simpler [12:08] 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] fwereade: that's true too [12:08] 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] fwereade: i wasn't sure whether you'd already got some code that implemented GetCmds already lurking somewhere though [12:09] rog, no -- it's the simplest thing I could predict it would be easy to get from a Context :) [12:10] fwereade: well, i'm glad about that at least - no downstream branches to mangle [12:22] TheMue: ping [12:22] rog: pong [12:22] TheMue: i got a test failure on TestUnitWatchPorts [12:22] TheMue: i've worked out the issue, and i think i have a slightly better way of working that test [12:23] TheMue: how about this? http://paste.ubuntu.com/949642/ [12:23] TheMue: this issue was a timeout BTW [12:23] TheMue: the receiver of the changes wasn't waiting long enough for the generator [12:24] 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] 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] TheMue: ok, so you've got a similar change in the offing? [12:24] rog: Yep [12:25] rog: Wait, I paste one example. [12:25] TheMue: cool. i'll ignore the test failures for the moment then. [12:27] rog: http://paste.ubuntu.com/949648/ [12:29] TheMue: that's cool. no need for the extra goroutine, of course, which i hadn't realised. nice. [12:29] rog: I followed an idea of William. [12:29] TheMue: 't'was a good idea [12:29] rog: Indeed. [12:38] fwereade: ping [12:38] TheMue, pong [12:39] fwereade: Just seen that you've got no roomie, like me. Shall I notify Marianna? [12:39] TheMue, sure :) [12:39] fwereade: OK, will do. [12:39] TheMue, I'm reasonablycivilised most of the time ;) [12:40] fwereade: I'll try my best to do so too. *lol* [12:40] TheMue: where do you find out your roomie? [12:44] rog: I went to the wiki and there "latest changes". [12:45] rog: There's a "PeopleDetail" page. [12:45] TheMue: got it [12:47] fwereade: Mail is sent. [12:47] rog, new cut at https://codereview.appspot.com/6120054/ [12:47] rog, actually hold off, I can simplify further [12:48] fwereade: yeah, jujucDoc and jujucPurpose can go, at least [12:48] rog, that was precisely what I realised :) [12:52] fwereade: LGTM [12:52] rog, cool, thanks [12:53] fwereade: i hope it feels ok [12:53] rog, ii's good, thank you :) [12:57] rog, btw, I've really come to appreciate lbox propose publishing all my drafts, really nice idea [12:57] fwereade: i like that too. and the fact that i have to have a clean branch when proposing [12:58] rog, yeah, that's saved me a lot of embarrassment :) [12:58] fwereade: i wish cobzr switch would do that check too actually [12:59] rog, I've actually given upon cobzr, it surprises me slightly more than bzr does and that makes me paranoid [12:59] fwereade: i find it works pretty well actually. [13:00] 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] rog, it's pretty clearly to do with a part of my brain that hasn't quite adapted to DVCSs in general [13:00] fwereade: so how do you set your GOPATH? [13:00] rog, so that's clearly soluble [13:01] rog, but the easy diffing is too much to give up [13:01] rog, sad to say, I'd rather just move directories ;) [13:01] fwereade: i usually just push to launchpad and diff against there. slow but quick enough for my purposes [13:02] rog, that would be fine if *something* I did didn't cause cobzr checkouts to occasionally forget their push branch :) [13:03] fwereade: ah, i have seen that before, i think. but nothing that caused too many problems. [13:27] rog: thanks for the reviews :) [13:27] andrewsmedina: np === rog is now known as Guest17887 === asavu_ is now known as asavu [13:45] Mornings! [13:46] heya niemeyer [13:47] fwereade: Hey [13:59] fwereade: I suspect the diff in https://codereview.appspot.com/6116049/ got mixed up with review points that we've sorted elsewhere [14:02] 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] Guest17887: I will improve testing for LXC using the same line you used forthe ssh === Guest17887 is now known as rogpeppe [14:39] andrewsmedina: that sounds reasonable. [14:45] * niemeyer missing fwereade at the moment [14:45] I don't understand why the checks in https://codereview.appspot.com/5845051/diff/17001/charm/charm_test.go are being removed.. [14:48] Ahh, I think I see.. it was moved to another test [14:50] Nice [15:12] So, have to leave. [15:13] niemeyer: Watcher moving is in at https://codereview.appspot.com/6131045/, could you please review? Thx. [15:14] 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] TheMue: Will do [15:18] TheMue: Cheers [15:18] * niemeyer => lunch too [15:53] niemeyer: i'm seeing a store test failure: http://paste.ubuntu.com/950070/ [15:57] niemeyer, fwereade: https://codereview.appspot.com/6128046/ [16:01] fwereade: https://codereview.appspot.com/6128046/ [16:01] fwereade_: https://codereview.appspot.com/6128046/ [16:02] rogpeppe, cheers [16:04] 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] rogpeppe, that sort of thing never happens at all ;p [16:04] rogpeppe, but tbh it's not clear what you can do about it... [16:04] fwereade_: yeah. i don't think it matters too much. [16:05] fwereade_: fix the build, then the tests can start working again [16:15] rogpeppe: Hmm.. is it failing consistently or some times? [16:16] niemeyer: just that once, but i haven't run all the tests since then. will try again. [16:16] rogpeppe: I will increase the timeout there [16:18] niemeyer, fwereade_: i'm off slightly early today. very shortly in fact. [16:19] rogpeppe, niemeyer: off in a few short minutes myself [16:19] * fwereade_ almost avoids saying something about friday, friday... [16:19] rogpeppe, fwereade_: Cool, I'll see you guys on Monday, hopefully [16:19] I'll be working from us-east, so we'll have little-to-no overlap [16:21] 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] rogpeppe: Woohay! [16:22] niemeyer: store tests passed that time BTW [16:22] rogpeppe: init is close [16:22] niemeyer: ? [16:22] rogpeppe: Cool.. it's the timeout indeed [16:22] rogpeppe: zkinit on server side [16:22] niemeyer: cool. i reckon that'll probably be done by the time i've finished the S3 upload code [16:23] 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] fwereade_: cheerio [16:24] 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] rogpeppe: I'm so excited about this stuff, btw [16:24] rogpeppe, happy weekend [16:24] niemeyer: 'xactly. "the shell script stuff" [16:24] rogpeppe: Yeha [16:24] niemeyer: me too. [16:25] 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] niemeyer: the go tool made it almost trivial... kudos to russ [16:26] rogpeppe: Hmm.. I don't think that's entirely related [16:26] rogpeppe: Kudos to all of them for having standalone binaries.. *that's* the huge facilitator [16:28] gn all, take care [16:28] 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] rogpeppe: Ah, I didn't realize you were going in that direction [16:29] fwereade_: Night man [16:29] niemeyer: hope it works ok for you. [16:29] rogpeppe: Thinking.. [16:30] rogpeppe: This is most awesome for dev, but it means you need the dev environment in place too.. [16:30] rogpeppe: The alternative I was thinking off was looking for the tools in $PATH [16:30] s/off/of [16:31] 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] niemeyer: i'd assumed non-devs would use public binaries [16:32] rogpeppe: Sure, that's an assumption we can make, but the question is why [16:32] rogpeppe: What are we trading off [16:34] niemeyer: i can easily add logic to find binaries in $PATH to the current code. [16:34] niemeyer: perhaps in the next CL? [16:35] rogpeppe: Yeah, we can even wait longer [16:35] rogpeppe: Until we have answers for that [16:35] 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 === flaviamissi_ is now known as flaviamissi